Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Discovery race condition?

Hi Bryan,

Bryan Hunt wrote:
<stuff deleted>


You are on the right track here, but consider the following:

   1. The org.eclipse.ecf.osgi.services.discovery bundle is started
   2. The org.eclipse.ecf.discovery bundle is started
   3. A bundle containing a discovery provider is started
   4. CompositeDiscoveryContainer.addContainer() is called
   5. The discovery provider connect() is called and services are
      discovered
   6. The org.eclipse.ecf.osgi.serives.discovery service tracker is
      called and the listener is added


The services discovered in step 5 will not be seen in step 6.

I believe this will only happen if the discovery provider...when it's started (3) does *not* call connect before it registers itself as a IDiscoveryLocator. That is...if the discovery provider calls connect prior to/before it's publication as an IDiscoveryLocator service, then the ServiceTracker created and opened in step 1, will be notified (via addService) when the IDiscoveryLocator is registered...and the addService implementation will then add a service listener synchronously as part of the IDiscoveryLocator service registration.

So the upshot is that if the connect call must be made for a given discovery provider to initialize itself properly (i.e. begin discovery) then it must be made before the IDiscoveryLocator is registered as a service (as that will trigger usage...i.e. service listeners will be added via service trackers).

This same problem happens when you do:

bundleContext.addServiceListener() ... you don't get the previously added services. I think the solution is to call:

IDiscoveryLocator.getServiceTypes() and getServices() after adding the listener.

I believe this can/could be done...to deal with the case of things 'previously' being discovered. I'll defer to Markus for comment about the existing implementation and/or comments about problems that could/might arise.
Scott




Back to the top