Bug 203105

Summary: Thread timed out waiting on initial start of RSE
Product: [Tools] Target Management Reporter: Martin Oberhuber <mober.at+eclipse>
Component: RSEAssignee: Martin Oberhuber <mober.at+eclipse>
Status: RESOLVED FIXED QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: normal    
Priority: P3 CC: dmcknigh, wb-rel
Version: 2.0Flags: dmcknigh: review+
Target Milestone: 2.0.1   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 142722    
Bug Blocks: 218304    
Attachments:
Description Flags
Patch decoupling plugin activation for UI adapters none

Description Martin Oberhuber CLA 2007-09-12 13:04:36 EDT 
+++ 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
------------------------------------------------
Comment 1 Martin Oberhuber CLA 2007-09-12 13:17:06 EDT 
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).
Comment 2 Martin Oberhuber CLA 2007-09-12 13:17:42 EDT 
Dave can you review this for 2.0.1? - Thanks!
Comment 3 Martin Oberhuber CLA 2007-09-12 15:59:01 EDT 
DaveM -- since DaveD seems not to be in today, could you review the patch?
Comment 4 David McKnight CLA 2007-09-12 16:22:52 EDT 
The patch looks fine to me.
Comment 5 Martin Oberhuber CLA 2007-09-12 16:38:50 EDT 
Patch applied, thanks