AW: [riena-dev] Race Condition on Client Startup

["Campo, Christian" <Christian.Campo@xxxxxxxxxxxx>]

Hi Olaf,

it would be really cool if you file that as a bug report. Because messages on riena-dev gets easily get lost and I really like to understand the problem that you are having. So a bugzilla would help to track the conversation and make a searchable item in the future.

However I think it was the right decision anyway to split the somewhat generic local provider from the bundle that creates the individual proxies.

I have a few questions:

- Why do you have a local provider and dont just directly use the OSGi Services as local services ?
- The second question is about the createLazyProxy line that you write about. You say "....the RemoteServiceFactory call and that classloader does not know the service class....". What is the service class ? Is that the service that makes the "local" protocol available or is that the actual service ? Wouldn't it help here if you make that bundle a buddy of the o.e.r.communication.core ? (not sure if that is a good design decision) Since that bundle (o.e.r.c.c.)  allows other bundle as buddy it would allow the RemoteServiceFactory to find your service class.

But as I said, lets have this discussion in bugzilla.

regards
christian campo

________________________________________
Von: riena-dev-bounces@xxxxxxxxxxx [riena-dev-bounces@xxxxxxxxxxx] im Auftrag von Olaf Fricke [Olaf.Fricke@xxxxxxxxxxxxxx]
Gesendet: Freitag, 5. Juni 2009 18:14
An: riena-dev@xxxxxxxxxxx
Betreff: [riena-dev] Race Condition on Client Startup

Hello everybody,

this week, I encountered a nasty race condition between bundles on the startup of a riena client. The situation was as follows:
1.) Some weeks ago, I wrote my own extension of "org.eclipse.riena.communication.core.remoteservicefactory" to provide a new communication protokoll "local" to be able to redirect service calls to a local implementation (mainly for testing purpose, but also valid for a printing service).
2.) I wrote a test bundle that uses a 'local' service and started everything with an OSGi Frameword runner. Everything worked fine.
3.) Now I integrated everything in our riena client and suddenly all my services were null, even the remote ones. Surprinsingly I never got any exception.

After debugging the riena client I discovered the following race condition:
- The bundle "org.eclipse.riena.security.client.startup" defines an "org.eclipse.riena.core.startups" extension point and is thus started very early from the riena core.
- Its activator registers two remote proxy objects for the IAuthenticationService.
- During that registration the very first RemoteServiceFactory is created, calling "Inject.extension(IRemoteServiceFactoryProperties.EXTENSION_POINT_ID)".
- The Injector resolves all extensions for the extension point and therefore loads the class of my own factory.
- Now comes the nasty part: The EclipseLazyStarter detects in its method postFindLocalClass that another ClasspathManager exists on the activation stack and therefore calls secureAction.start(bundle, Bundle.START_TRANSIENT);
- That call triggers the Activator of my own communication bundle. In that activator all remote and local services are loaded and remote proxies are created. Unfortunately, the factories for the proxies are not ready yet.
- The method RemoteServiceFactory#createProxy cannot find a matching protocol and thus returns null.
- The fallback is to call RemoteServiceFactory#createLazyProxy. But that method fails in my environment, because it uses the ClassLoader of the RemoteServiceFactory class and that classloader does not know the service class (the current context classloader would know it!).
- I end up with a null value for all my service proxies.


I worked around this race condition by splitting my bundle into two: the first bundle contains everything for the local protocol, the second one contains the activator for creating the proxy object. Due to this split the first bundle can be fully activated and thus the protocols can be registered, before the second bundle starts.

Another solution could be to create the two needed IAuthenticationService proxies as lazy proxies, but I have not tried it.

I hope my mail will help, if anybody encounters a similar race condition.

Best regards,
Olaf Fricke