[
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 1:19 PM, Scott Lewis wrote:
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.
What if connect() discovers services, or connect starts a thread that
discovers services before the listener is added?
It seems to me that this would be a case that would benefit from calling
getServiceTypes() and getServices() at the time that the osgi.discovery
service listener is added (i.e. in the addService impl for the
IDiscoveryLocator service tracker)....so that previously discovered
services will result in osgi.discovery DiscoveredServiceTrackers being
called when the osgi.discovery/distribution is started.
So if we can get Markus' agreement that this is reasonable (and doesn't
create other problems)...and create an enhancement request/bug, then
we'll add it. Probably have to be after Galileo.
Scott
