Community
Participate
Working Groups
It turns out that nothing prevents users from running multiple instances of Eclipse using the same configuration location. This might not be a problem if the configuration information is not modified by such Eclipse instances; however, it becomes an issue if they do. For instance, in the bug 128138 we discovered that should both instances install bundles, the new bindle IDs used by the instances will be the same. The Instance1 will install Bundle1 and it will be given Id of 101; the Instance2 will install Bundle2 and it will be given the same Id of 101. Both Bundle1 and Bundle2 will be assigned the same location (in our case workspace\.metadata\.plugins\org.eclipse.pde.core\All Runtime Tests\org.eclipse.osgi\bundles\101\1\bundlefile) causing manifest information from one bundle to be overwritten by another bundle. It turns out that there is no mechanism for discovering proper bundle Id to use in this situation. Also, any other information cached in the configuration might be vulnerable in this use case. On the other hand, we can't just prohibit using multiple instance of Eclipse over the same configuration location because of the shared installs.
The framework is actually designed and intended to support running multiple instances of one configuration simultaneously. Ther may be a bug but this is what the FileManager code is all about. We can't prevent concurrent installs but we can detect when there is a potential lost update. Are you saying there is a bug?
If design intent was to allow multipe instances of Eclipse to be run using the same configuration location while installing new bundles, then it is certainly a bug.
Here is the "bug". When bundles are installed we cache the bundle information (including the next bundle id) in memory and periodically save this information to disk. If two instances using the same configuration install bundles at the same time then the same bundle id will be used by both instances. But this is the least of my concerns. When this situation occurs one instance does not know what the other instance has installed, it only knows about what bundles were installed at the time it was launched. IMO the correct thing to do is to lock the configuration once an instance modifies the configuration. No other currently running instance should be able to modify the configuration until the modifying instance has saved that bundle data and the other instance has been loaded from the newly saved data (this would likely require these instances to be relaunched).
yup. We could even fail the install if you are in teh second one and the config area is locked.
>No other currently running instance should be able to modify the configuration until the modifying instance has saved that bundle data and the other instance has been loaded from the newly saved data" (this would likely require these instances to be relaunched). I think this is very restrictive. We should try to read and write eagerly the bundle id (this would have a hit on first startup).
re: comment 5 Again the bundle ID is the least of my concerns. One session has no clue what the other session has installed. If you have two sessions running from the same configuration, session 1 installs Bundle A, B, and C. Then session 2 tries to install Bundle A, B, and C. If you only saved the bundle ID eagerly then session 2 will install bundle A, B, and C even though they were already installed by session 1 (but the bundle ID's would not be reused at least ;-) Just to be clear this is not a new problem, been there since 3.0. The correct solution would involve something like this. 1) When the bundle data is changed the modifying session locks the configuration then it must check that it has the latest .bundledata. If it does not then it should fail the modification and unlock the configuration. 2) After an agent (e.g. update.configurator) has finished modifying the configuration then it can call some method (maybe on PlatformAdmin) to force a save and unlock the configuration. This should allow the session tests to work because the launching session will have finished modifying the bundledata (and will have synch'ed the .bundledata) before the session test is launched from the same configuration. So the session test should be able to modify the bundledata. A more advanced solution would allow the second session to attempt to reload the .bundledata from disk if it detected that the one from memory was out of sync with the one on disk.
+1 to comment 6
I will investgate the solution for M6. The more advanced solution (reloading the bundledata from the second session) is too much for M6 IMO.
agreed
putting milestone back for the less advanced solution.
I discussed this more with Pascal. He reminded me of a design decision which we made back in Eclipse 3.0 WRT shared configuration areas. We allow multiple instances of eclipse to run from the same configuration. If more than one of the running configurations attempts to modify the configuration (by installing/uninstalling/updating bundles etc.) then the last one that persists wins. If we stick with this same design (which I think we should this late in the 3.2 cycle) then we really only have a bug in the fact that two different instances may attampt to use the same bundle ID when installing bundles into the same configuration at the same time. To prevent this we should use Pascals suggestion in comment 5 as a solution.
Created attachment 35937 [details] patch to agressively read/write the next bundle id Pascal, can you review this patch. I may have gone overboard with the extra locker, but I did not see another safe way to synchronize the next bundle id between multiple instances.
Pascal, disregard the patch. It needs work. Session tests fail ...
Have to be careful about startup time (even if it is first startup). Writing a the latest bundle number for every new bundle seem problematic. We should be able to do something with all the locking support we have.
Created attachment 35994 [details] new patch Ok, here is a new patch. This uses a different strategy. Instead of locking in the framework this patch assumes the agent installer is going to lock. Perhaps this can happen by locking the configuration location before a modification is made to the configuration and unlocking it after the configuration has been modified. This patch ensures that the latest bundle id (still stored in .bundledata) is saved to disk after a batch process has finished and at least one bundle was installed. Currently the only batch process is when bundles are resolving/refreshing. When a bundle is installed we make sure the latest bundle id is loaded from the latest version of the .bundledata file. Note that currently install agents (EclipseStarter and update.configurator) are not locking the configuration. This can lead to issues if more than one instance is installing bundles concurrently. Pascal, please review. Thanks.
Pascal, any chance to review? Not sure I would want to release this late in M6 cycle anyway.
I'm not confident with releasing that now. Why don't we hold on until 3.3?
slipping milestone
Created attachment 63943 [details] updated patch updated patch for 3.3. When this patch is applied some of the session tests are failing. It is unclear why they are failing. We should not do anything this late in 3.3.
Hello Thomas, do you still plan to work on this? Why has Pascal Rapicault meant (on 2006-05-01), that "Sharing the configuration has nothing of adventureous", when this bug is still open? (https://bugs.eclipse.org/bugs/show_bug.cgi?id=139319#c13) BTW., could someone please fix this bug's summary to "multiple instances"?
(In reply to comment #20) > Hello Thomas, do you still plan to work on this? > > Why has Pascal Rapicault meant (on 2006-05-01), that > "Sharing the configuration has nothing of adventureous", when this bug is still > open? > (https://bugs.eclipse.org/bugs/show_bug.cgi?id=139319#c13) > > BTW., could someone please fix this bug's summary to "multiple instances"? Are you seeing this issue cause you problems in the field. I think Pascal was trying to say that running many instances from a shared configuration is pretty common and that we don't see any major issues that are forcing users of eclipse to have a separate install of eclipse for each instance they want to run. Most eclipse committers I know have many instances running at the same time and do not run into issues.
(In reply to comment #21) > Are you seeing this issue cause you problems in the field [?] No, thank you for asking. I want to be able to work in parallel on different branches of my programming project and I found this bug while researching how to do this. But it seems not to pose any problems to me.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
No plans to address this issue.
