Description Thomas Watson 2011-02-15 11:01:06 EST

Cloning bug to release to 3.4.2+

+++ This bug was initially created as a clone of Bug #330716 +++

Build Identifier: Eclipse 3.4.2

Our product contains a large number of bundles (in the hundreds). Periodically
timeout messages appear during the start of the product. The following is an
example:

2010/02/26 19:37:48.890 WARNING While loading class
"com.mypackage.Activator", thread "Thread[MyMergeThread:com.otherpackage.kernel:START,5,main]" timed
out waiting (5000ms) for thread "Thread[Thread-1,5,main]" to finish starting
bundle "update@../../myproduct/eclipse/plugins/com.mypackage.console.jsf_1.2.0/
[318]". To avoid deadlock, thread
"Thread[MyMergeThread:com.otherpackage.kernel:START,5,main]" is
proceeding but "com.mypackage.Activator" may not
be fully initialized. ::class.method=unknown
::thread=MyMergeThread:com.otherpackage.kernel:START
::loggername=org.eclipse.osgi
   org.osgi.framework.BundleException: State change in progress for bundle
"update@../../myproduct/eclipse/plugins/com.mypackage.console.jsf_1.2.0/"
by thread "Thread-1".
                 at
org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1144)
                 at
org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:263)
                 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:427)
                 at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)
                 at
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:370)
                 at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:446)
                 at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:399)
                 at
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:387)
                 at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)
                 at java.lang.ClassLoader.loadClass(ClassLoader.java:609)


We understand and don't disagree with the reasons for issuing this sort of
message. The issue is that the timeout value (5000ms) is hard-coded and is not
configurable. In many cases if the timeout value was longer the processing
would complete successfully. Allowing the timeout value to be configurable
would also help us determine when actual deadlock conditions occur.


Reproducible: Sometimes

Steps to Reproduce:
Not easily reproducible. See details above.