Community
Participate
Working Groups
I20070220 When the workbench is restarted, if 2 threads (e.g. the 'Initializing Java Tooling' thread and the UI thread) are initializing classpath containers at the same time, it can happen that a project is touched (IProject#touch(...)). The scenario is as follows: 1. The first thread is initializing all containers (JavaModelManager.batchContainerInitializations being set to true) 2. At the same time, the second thread initializes 1 container that is not yet initialized by the first thread. In this case batchContainerInitializations is already set to false. 3. The second thread will then touch the project in the SetContainerOperation. Note the first thread doesn't touch projects it initializes because it marked all containers as being initialized by itself, and thus JavaModelManager#containerPutIfInitializingWithSameEntries(...) returns true since entries are the same. The second thread touches the project, because the container is not marked as being initialized, and thus containerPutIfInitializingWithSameEntries(...) returns false right away without looking at the entries.
Created attachment 59988 [details] Proposed fix and regression test The proposed fix consists in removing the test in containerPutIfInitializingWithSameEntries(...) that checks if the container is being initialized. Without this check, entries are compared and no further work is done if they are the same.
Proposed fix and regression test released for 3.3M6 in HEAD.
IProject#touch(...) is still called in other scenario. To reproduce, shutdown a full source workbench with a Java editor opened, and the Package Explorer 'link with editor' option. Then add a breakpoint in IProject#touch(...) and start the workbench under the debugger. Observe: the breakpoint is hit on almost every restart.
Created attachment 60141 [details] Enhanced fix and modified test The enhanced fix brings the following changes: - the optimization in containerPutIfInitializingWithSameEntries(...) and variablePutIfInitializingWithSameValue(...) now uses first the previous container value, then the previous session value to compare with the current value - for containerPutIfInitializingWithSameEntries(...), the optimization happens only if the container is being initialized (since some container returns the same entries for the old and new container) - initializeAllContainers(...) keeps the 'initialization in progress' state of container that are being initialized before calling initializeAllContainers(...)
Enhanced fix and test released for 3.3M6 in HEAD.
Could not reproduce problem in 3.2.x, so it looks like this problem was introduced in 3.3 only.
Verified for 3.3 M6 using v_744. (Ran the test before and after patch application. The test passes with v_744 and fails with the code dated 20070227.)
