Re: [ecf-dev] Discovery race condition?

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bryan Hunt wrote:

Hi,

> IDiscoveryLocator.getServiceTypes() and getServices() after adding the
> listener.  This should also solve the bundle start order problem as well.

I would not call IDL.getServices() inside of
org.eclipse.ecf.internal.osgi.services.discovery.Activator.start(BundleContext).
It's a blocking call and potentially might not return in a "timely
manner" as required by OSGi. Better do it asynchronously.

> I think the workaround for me is to override
> AbstractDiscoveryContainerAdapter.addServiceListener() and call the
> listener for any existing discovered services.

a) Do you have some list of cached service events in your discovery
provider? When do you expire events inside the cache?

b) Think about aListener adds, removes and adds itself as a service
listener again. It will receive the same service events twice. In
general there are cases where a service listener is not interested in
past service events.

That's why e.g.
org.eclipse.ecf.discovery.ui.model.resource.ServiceResource.ServiceDiscoveryListener.connect()
first registers itself as a discovery service listener and calls
IDL.getServices() afterwards.
The idea of wrapping this pattern in something like a
DiscoveryServiceTracker sounds promising to me. It could reuse
org.eclipse.ecf.discovery.IServiceListener for the TrackerCustomizer.

Cheers
Markus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkovc2oACgkQH/hL0IhDj1lstwCgsXnz1xqlrMccC/0MLsTgkJyJ
H1kAn3wwpFpQE+EVXc1m7yqJ36c+soT4
=h2WU
-----END PGP SIGNATURE-----