Thanks for the quick reply. You are right, I wrongly assumed that the 'enable' method caused a new thread to be spawned. I think I found the right culprit now. I tried both version 1.0.0 and 1.0.1-SNAPSHOT (snapshot built today).
What I am seeing, is that when starting the bundle (after stopping it first), the enable method (AbstractComponentManager) is called starting an 'enableInternal' (including an activateInternal) on the component actor thread. Approximately at the same time, an update call is made from the configuration manager (on some thread from the CM, through method 'update' in ImmediateComponentManager's anonymous ManagedService inner class) resulting eventually in a call to 'reactivate' which first deactivates (deactivateInternal) on the current thread (CM thread). That's where things clash, I guess. I hope this explanation is helpfull, I haven't been able to extract a log (yet). Regards, Paul -----Oorspronkelijk bericht----- Van: Felix Meschberger [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 6 mei 2008 14:59 Aan: [email protected] Onderwerp: Re: SCR race condition Hi, Am Dienstag, den 06.05.2008, 09:43 +0200 schrieb Paul Neyens: > I noticed something strange using declarative services. It seems that > when stopping and starting a bundle that has a component which is also > registered as a service, this service is registered twice from time to > time. This should not be the case. > The problem seems to be that the method 'enableInternal()' in > org.apache.felix.scr.impl.AbstractComponentManager is called twice in > two separate threads (method 'enable()' spawns a new thread on every > call). After adding a 'synchronized' modifier to method > 'enableInternal()', I was unable to reproduce the problem again. There > may however be a more appropriate solution... Hmm, I don't think this is correct. The enable() method creates a Runnable instance which calls enable. This Runnable instance is scheduled for the "SCR Actor" thread. So enableInternal is always called serialized. In fact, when a bundle is restarted, stopping the bundle is done first, scheduling disablement, next the bundle is starting and the component is scheduled for enablement. What version of SCR are you using ? Can you enable debug logging and create a JIRA issue with the create log information so, that I could try to follow the call trace ? This logging should be done with the latest SNAPSHOT as it contains more log statements than the latest released bundle version. Regards Felix --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
