Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #142722 +++ With TM I20070816-0800, I'm seeing a bug again that we though was resolved in TM 1.0.1: On the very first start of a downloaded RSE on a fresh blank workspace, the following exception is logged to the PDE Error Log. I also observe that opening the RSE Perspective is slow. !ENTRY org.eclipse.osgi 2 0 2007-08-30 06:19:11.749 !MESSAGE While loading class "org.eclipse.rse.subsystems.shells.core.subsystems.servicesubsystem.IServiceCommandShell", thread "Thread[main,6,main]" timed out waiting (5000ms) for thread "Thread[Worker-6,5,main]" to finish starting bundle "update@plugins/org.eclipse.rse.subsystems.shells.core_2.0.1.v20070808.jar [211]". To avoid deadlock, thread "Thread[main,6,main]" is proceeding but "org.eclipse.rse.subsystems.shells.core.subsystems.servicesubsystem.IServiceCommandShell" may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle "update@plugins/org.eclipse.rse.subsystems.shells.core_2.0.1.v20070808.jar" by thread "Worker-6". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1141) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:258) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:400) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:417) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:189) at org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:340) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:408) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:369) at org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:357) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:83) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) -----------Enter bugs above this line----------- TM I20070816-0800 installation : eclipse-SDK-3.3 (I20070625-1500), cdt-4.0.0, emf-2.3.0 RSE install : I20070816-0800 java.runtime : Sun 1.5.0_11 os.name: : Windows XP 5.1, Service Pack 1 ------------------------------------------------
Created attachment 78209 [details] Patch decoupling plugin activation for UI adapters The problem seems to be, that when RSE initially loads and needs the SystemRegistry the first time (through InitRSEJob), a very long sequence of plugin activations is started: SystemRegistry instantiates subsystem configurations as needed subsystem configurations activate e.g. files.core files.core load the UI adapters unconditionally files.ui requires shells.core shells.core load shells.ui unconditionally ... At some point, there may be a recursive sequence of activations: Because the Main Thread can instanciate the SystemRegistry, which loads the subsystems, but the InitRSEJob (running in a different thread) loads the profiles! This may essentially deadlock, depending on the exact timing of when and by whom the SystemRegistry is first needed, versus when the InitRSEJob runs. To fix the issue in the longer term future, we should consider getting rid of asynchronously filling the SystemRegistry in a Job; and, we should make plugin activation of subsystems deferred. Different bugs are used to track both these approaches. In the meantime, it should help to decouple UI plugin activation from the Core plugin activation by running them in a separate thread; then, the Core plugin is activated earlier and doesn't have to wait for UI to fully activate, so the deadlock should not occur. Attached patch does exactly that (decouple UI plugin activation to separate thread).
Dave can you review this for 2.0.1? - Thanks!
DaveM -- since DaveD seems not to be in today, could you review the patch?
The patch looks fine to me.
Patch applied, thanks
