[
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:
On Jun 9, 2009, at 11:07 AM, Scott Lewis wrote:
Hi Bryan,
The listener is registered in the Activator of the
org.eclipse.ecf.osgi.services.discovery bundle, which is started when
the org.eclipse.ecf.osgi.services.distribution bundle is started.
So the key thing is that the
org.eclipse.ecf.osgi.services.distribution bundle must be started in
order to get everything going in a lazy start environment (like
Eclipse)...or a class in o.e.e.osgi.services.distribution accessed,
of course (as this will also start o.e.e.osgi.services.distribution
and discovery).
If the osgi distribution (and discovery) bundles are not started,
then yes...they will miss discovered services (assuming the ecf
discovery *has* been started). This constraint isn't unique to
ECF...as there was nothing in the spec (in my most recent reading of
RFC 119) that discusses starting/start order in various environments.
Even if they are started prior to the discovery provider, I assert
there is still a race condition. The listener is added asynchronously
to the provider which could have already discovered it's services,
Not sure if I understand what you mean 'listener is added asynchronously
to the provider'. The listener is added in the start method of the
org.eclipse.ecf.osgi.discovery bundle. If this is what you mean by
asynchronous, then do you mean asynchronous to the discovery provider
being started?
If so, then yes...this starting of the osgi.discovery bundle can happen
asynchronous to the starting of the discovery provider.
could be in the process of discovering services, or may not discover
any services for several hours.
Sure. This is why, in general, it makes sense to start the osgi
distribution/discovery code as early as possible. But we cannot
require/guarantee when any of our bundles get started (or even if they
get started)...in fact, for distribution with Eclipse we explicitly
*can't* start them (since Eclipse uses lazy start).
Isn't this the exact same problem as listening to regular OSGi
services and why the ServiceTracker was created?
We do use a service tracker to track the IDiscoveryLocator, it's on line
82 in org.eclipse.ecf.internal.osgi.services.discovery.Activator. The
call to locatorTracker.open() on line 85 will end up calling
LocatorTrackerCustomizer.addingService(servicePublicationHandler), which
adds a service listener to the discovered IDiscoveryLocator.
I think I recognize what you are trying to say (correct me if I'm
wrong): isn't it possible that an ECF discovery provider (e.g.
zeroconf/slp) could discover services all day long, and the osgi
discovery would never be triggered...because it was never started, and
therefore no listener was registered, therefore no notifications. Yes,
that is certainly true. But it's not obvious (to me) what we can do
about this given the OSGi lazy starting (other than what we have
done...which is to start osgi discovery as part of osgi distribution
being started)...and no spec-based guidance on start order.
Scott
