On Tuesday 29 January 2008 16:55, Karl Pauls wrote: > Could you have them retry using Felix 1.0.3? This might be related to > some of the concurrency things we fixed. > > In case they can not be bothered retrying on Felix 1.0.3 then maybe > they can provide a minimal config file that only uses publicly > available bundles and has this issue (then I can look into it).
I am looking at the code in the trunk, and it appears that the locking that triggers this is in place. As always, it is a bit tricky to setup threading problems. SO, I would like to run a "head exercise" first. 1. The Starter thread "FelixStartLevel" locks the ModuleFactoryImpl instance in R4SearchPolicyCore.resolve(). 2. The Configuration Admin thread "Configuration Updater" calls the LogService with the Configuration instance, which leads to Log4J locks on its own RootLogger and calls ClassLoader.loadClass() on something found in the configuration. This leads to trying to acquire the ModuleFactoryImpl lock either in R4SearchPolicyCore.resolve() or in the provided stack trace R4SearchPolicyCore.getInUseCandidates() due to a ClassNotFound in the previous step. 3. The "FelixStartLevel" thread reaches m_logger.log(Logger.LOG_DEBUG, "WIRE: " + wires[wireIdx]); in R4SearchPolicyCore.createWires() and he log() method will try to acquire the RootLogger lock. 4. DEADLOCK. I agree this is very special to the LogService, since Felix binds to it and uses it for its internal use, and the responsibility is across two different systems. Suggestions are welcome. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug
