[#CMP-675] The dynamic addition of resource mappings is not correctly updating the AbstractParallelGpsDevice#entities

Compass

The dynamic addition of resource mappings is not correctly updating the AbstractParallelGpsDevice#entities

Created: 10/Jul/08 05:13 PM Updated: 12/Jul/08 03:27 AM

Component/s:

Compass::Core

Affects Version/s:

2.1.0 M1

Fix Version/s:

2.1.0 M2

Environment:

Windows XP pro

Description

« Hide

The field AbstractParallelGpsDevice#entities is being updated only at start-up time. Hence if new mappings are dynamically added to compass they do not show up in this field and hence a index() operation for such aliases fails.
Also when a new dynamic resource mapping is added and the compass rebuilt in the debugger now there are two compass executor threads and these keep increasing with additional new mappings. These do disappear but after a tiem lag and sometimes one can see multiple compass executor and compass close threads at the same time. Not sure if this is the desired behavior.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Shay Banon added a comment - 11/Jul/08 04:55 AM

Regarding the threads that are kept around, this is because the old Compass instance is not closed immediately, but (by default) closes after a minute, to allow for any on going indexing operations to end. You can configure the interval.

Regarding the Gps, I know of this. I am actually very close to implementing this feature to seamlessly work with Gps as well. You can always call stop/start on the CompassGps instance in order for it to take the new mappings into account.

[ Permlink | « Hide ]

Shay Banon added a comment - 11/Jul/08 04:56 AM

ok, It should work now. You can try 2.0 M2 nightly later on from tonight to check if it works.

[ Permlink | « Hide ]

arsee added a comment - 11/Jul/08 12:12 PM

Thanks a lot Shay.

I had a couple of questions regarding the behavior for adding dynamic mappings. What happens if some of the threads from the old instance are still doing some operation which might be long running? Would those operations fail when finally the old instance is shutdown or would they be silently ignored? Could this possibly lead to data corruption? What if the application wants to stop at the point where there are more than one instance of compass running? would they all stop and close immediately or would they take some time to stop and close (i.e. finish the tasks and then only stop). And what would be the behavior if say for example a index delete is called when there are still two instances of compass running.
Also isn't there a way to implement this by not creating a new instance? Definitely I do not understand the complete internal workings of compass. But it would be nice to make the usage of getting aliases always dynamic, i.e. if these are not pre-stored at the time of start-up but always calculated. This way it wouldn't be required to create a new instance of compass. Like earlier in my application I had implemented the solution by doing a hot replace... now I avoided doing a hot replace whenever an alias was deleted, its like I was removing the alias lazily whenever the compass has to restart (due to addition of a new alias or juts a normal restart). Rebuilding compass takes some time hence a solution that avoided creating a new instance would be more desirable.

Also by when would M2 be available as a release?

[ Permlink | « Hide ]

Shay Banon added a comment - 12/Jul/08 03:27 AM

The rebuild operation close process of the old Compass instance has exactly the same "problems" that you might have when closing your application.

This feature could have been implemented by calculating everything dynamically each time. This is not the "spirit" of Compass from the beginning (just think about all the concurrency bottlenecks that you will have because of that in case dynamic changes of internal data structures are allowed). There were two options, the first, do what I did, which is good enough, I think. The second was to rewrite large parts of Compass, and degrade it, in order to support what you suggested.