Community
Participate
Working Groups
Got this error when starting the host.ds example osgi> !SESSION 2010-06-03 00:20:12.396 ----------------------------------------------- eclipse.buildId=unknown java.version=1.6.0_20 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=nl_NL Framework arguments: -application org.eclipse.ecf.examples.remoteservices.hello.ds.host.HelloHostDS Command-line arguments: -application org.eclipse.ecf.examples.remoteservices.hello.ds.host.HelloHostDS -data C:\Users\jongw\workspaces\nntp/../runtime-HelloServiceDSHost(zeroconf,generic).product -dev file:C:/Users/jongw/workspaces/nntp/.metadata/.plugins/org.eclipse.pde.core/Hello Service DS Host (zeroconf,generic).product/dev.properties -os win32 -ws win32 -arch x86 -consoleLog -console -consoleLog !ENTRY org.eclipse.osgi 2 0 2010-06-03 00:20:22.501 !MESSAGE While loading class "org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl$DiscoveredEndpointEvent", thread "Thread[JMDNS Discovery Thread,5,main]" timed out waiting (5000ms) for thread "Thread[Start Level Event Dispatcher,5,main]" to finish starting bundle "org.eclipse.ecf.osgi.services.distribution_1.2.0.qualifier [17]". To avoid deadlock, thread "Thread[JMDNS Discovery Thread,5,main]" is proceeding but "org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl$DiscoveredEndpointEvent" may not be fully initialized. !STACK 0 org.osgi.framework.BundleException: State change in progress for bundle "initial@reference:file:../../../workspaces/nntp/org.eclipse.ecf.osgi.services.distribution/" by thread "Start Level Event Dispatcher". at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1077) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:282) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.serviceChanged(DiscoveredServiceTrackerImpl.java:151) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.notifyDiscoveredServiceTrackers(ServicePublicationHandler.java:103) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.serviceDiscovered(ServicePublicationHandler.java:73) at org.eclipse.ecf.discovery.AbstractDiscoveryContainerAdapter.fireServiceDiscovered(AbstractDiscoveryContainerAdapter.java:120) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer.fireDiscovered(JMDNSDiscoveryContainer.java:366) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$2.run(JMDNSDiscoveryContainer.java:327) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$1.run(JMDNSDiscoveryContainer.java:125) at java.lang.Thread.run(Unknown Source) Caused by: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException ... 21 more Root exception: org.eclipse.osgi.framework.internal.core.AbstractBundle$BundleStatusException at org.eclipse.osgi.framework.internal.core.AbstractBundle.beginStateChange(AbstractBundle.java:1077) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:282) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:417) at org.eclipse.osgi.internal.loader.BundleLoader.setLazyTrigger(BundleLoader.java:265) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:106) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:453) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:216) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:393) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:469) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:422) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:410) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.ecf.internal.osgi.services.distribution.DiscoveredServiceTrackerImpl.serviceChanged(DiscoveredServiceTrackerImpl.java:151) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.notifyDiscoveredServiceTrackers(ServicePublicationHandler.java:103) at org.eclipse.ecf.internal.osgi.services.discovery.ServicePublicationHandler.serviceDiscovered(ServicePublicationHandler.java:73) at org.eclipse.ecf.discovery.AbstractDiscoveryContainerAdapter.fireServiceDiscovered(AbstractDiscoveryContainerAdapter.java:120) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer.fireDiscovered(JMDNSDiscoveryContainer.java:366) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$2.run(JMDNSDiscoveryContainer.java:327) at org.eclipse.ecf.provider.jmdns.container.JMDNSDiscoveryContainer$1.run(JMDNSDiscoveryContainer.java:125) at java.lang.Thread.run(Unknown Source)
This patch solved it for me: ### Eclipse Workspace Patch 1.0 #P org.eclipse.ecf.examples.remoteservices.hello.ds.host Index: products/Hello Service DS Host (zeroconf,generic).product =================================================================== RCS file: /cvsroot/rt/org.eclipse.ecf/examples/bundles/org.eclipse.ecf.examples.remoteservices.hello.ds.host/products/Hello Service DS Host (zeroconf,generic).product,v retrieving revision 1.1 diff -u -r1.1 Hello Service DS Host (zeroconf,generic).product --- products/Hello Service DS Host (zeroconf,generic).product 12 May 2010 04:27:07 -0000 1.1 +++ products/Hello Service DS Host (zeroconf,generic).product 2 Jun 2010 22:22:30 -0000 @@ -49,10 +49,13 @@ </plugins> <configurations> - <plugin id="org.eclipse.ecf.examples.remoteservices.hello.ds.host" autoStart="true" startLevel="0" /> - <plugin id="org.eclipse.ecf.osgi.services.distribution" autoStart="true" startLevel="0" /> - <plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="2" /> + <plugin id="org.eclipse.ecf.examples.remoteservices.hello.ds.host" autoStart="false" startLevel="0" /> + <plugin id="org.eclipse.ecf.osgi.services.discovery" autoStart="true" startLevel="0" /> + <plugin id="org.eclipse.ecf.osgi.services.distribution" autoStart="true" startLevel="3" /> + <plugin id="org.eclipse.ecf.provider.remoteservice" autoStart="true" startLevel="1" /> + <plugin id="org.eclipse.equinox.common" autoStart="true" startLevel="1" /> <plugin id="org.eclipse.equinox.ds" autoStart="true" startLevel="2" /> + <plugin id="org.eclipse.osgi.services" autoStart="true" startLevel="0" /> </configurations> </product>
Hi Wim. I've never seen this in my own running of the ds example (host I guess). Is this easily reproducible? Any conditions that particularly affect it? The only reason I ask is that in general...and to the extent possible...I would like to avoid fussing with start levels of the example bundles...since I don't think it will be obvious/clear to people why such start levels are set the way that they are.
Maybe for ECF 3.4 we can add a plan item and work on making the bundles/examples start level unaware.
Hi, I agree. But fiddling with start levels is the biggest time consumer so far in working the ECF 3.3 and Zookeeper. I am sure it must be something in the ZK bundle but it is still pretty annoying. Could it be somebody's hardware being fast or slow that causes timing problems? When I start the DS straight out of the CVS repository in my workspace i get: "Thread[JMDNS Discovery Thread,5,main]" timed out waiting (5000ms) for thread "Thread[Start Level Event Dispatcher,5,main]" to finish starting bundle "org.eclipse.ecf.osgi.services.distribution_1.2.0.qualifier [17]" every time.
Is there any more evidence about what's going on with this problem?...or is it still a problem for you Wim? I am still unable to reproduce.
Haven't seen it for a while.
