That's right ... it worked in the same application previously too. But after adding scr to the bundle also containing blueprint the bug was triggered. I agree with Felix M. that a week cohesion is the reason why it appears in our application, indicated by the number of dependencies between the bundles used in our application and the resulting number of bundles/components that need to be refreshed/reinitialized after a single bundle has been deployed. Unfortunately we don't have time to rework our architectural design.
-----Ursprüngliche Nachricht----- Von: Neil Bartlett [mailto:[email protected]] Gesendet: Mittwoch, 25. September 2013 15:25 An: users Betreff: Re: Are bundles containing declerative services and blueprint possible? On Wed, Sep 25, 2013 at 1:39 PM, Rudolph, Dirk <[email protected]>wrote: > Ok, done. > > Splitting up the bundles didn't solve the issue for us... > > The Blueprint Extender still can't acquire the bundle lock because > global lock is hold by another thread. So the reason of the bad > restart behavior is the weak cohesion of our application (when I redeploy > "nearly the whole" > container is restarted ^^) modules and we have to do some refactoring. > > But in my eyes it should also be possible to use ds and blueprint at > the same time without taking care one the startup behavior ... just my > two cents. > It nearly always is possible. I've seen it done many times. Just something about your application appears to trigger a bug... > > -----Ursprüngliche Nachricht----- > Von: Felix Meschberger [mailto:[email protected]] > Gesendet: Mittwoch, 25. September 2013 11:07 > An: [email protected] > Betreff: Re: Are bundles containing declerative services and blueprint > possible? > > Hi > > Am 25.09.2013 um 10:42 schrieb Rudolph, Dirk: > > > That's right. I also think the issue is related to FELIX-3067. > > Should I > describe the issue their again (just for completeness)? > > Yes, that might be a good idea. And you also might want to attach the > thread dump > > Regards > Felix > > > > > We will split the bundles based on technology used. > > > > Thanks a lot, > > Dirk > > > > -----Ursprüngliche Nachricht----- > > Von: Felix Meschberger [mailto:[email protected]] > > Gesendet: Mittwoch, 25. September 2013 10:01 > > An: [email protected] > > Betreff: Re: Are bundles containing declerative services and > > blueprint > possible? > > > > Hi > > > > Am 25.09.2013 um 09:21 schrieb Rudolph, Dirk: > > > >> Thanks for your response. > >> > >> The state of the bundle is ACTIVE. Unfortunately the original > >> Exception > causing the previously attacked ISE isn't passed to the ISE itself and > therefore not in the stacktrace: > >> > >> ERROR: [Thread[FelixDispatchQueue,5,main]] Waited too long to > >> acquire > the global lock own by Thread[FelixPackageAdmin,5,main]; giving up. > >> java.lang.IllegalStateException: [Thread[Blueprint Extender: > >> 3,5,main]] > Waited too long to acquire lock for bundle ******* [516] owned by null > (lockcount=0) > >> at > org.apache.felix.framework.Felix.acquireBundleLock(Felix.java:4756) > >> at > org.apache.felix.framework.Felix.registerService(Felix.java:2820) > >> at > org.apache.felix.framework.BundleContextImpl.registerService(BundleCon > textImpl.java:251) > >> at > org.apache.felix.framework.BundleContextImpl.registerService(BundleCon > textImpl.java:229) > > > > Just know that this is an Adobe build of the framework which > > contains > this deadlock prevention not contained in the official release. The > problem looks related to FELIX-3067 [1]. > > > >> > >> This happens because m_globalLockThread isn't null. Just for my > understanding: Why is it necessary for the FelixPackageAdmin Thread to > hold a global lock and not a bundle lock only? > > > > Because the resolving bundle dependencies may involve multiple > > bundles > at the same time which must be prevented from having their state changed. > > > >> > >> Just for summary: A quick solution would be to split the bundle in > >> one > containing blueprint and one containing SCR. Another solution would be > trying to update org.apache.felix.scr to the latest release (with > adobe CQ this can cause "some" of problems ;-)) > > > > Yes, splitting might be a good idea. > > > > Another idea would be to create smaller cohesive bundles with less > coupling to other bundles. For example if you have Import-Package > statements listing roughly 50+ packages is an indicative sign that the > respective bundle is not very cohesive. > > > > Regards > > Felix > > > > [1] https://issues.apache.org/jira/browse/FELIX-3067 > > > >> > >> Attached you will find the full thread dump, captured on ISE > >> breakpoint > in registerService(). > >> > >> Thanks a lot, > >> Dirk > >> > >> > >> -----Ursprüngliche Nachricht----- > >> Von: David Jencks [mailto:[email protected]] > >> Gesendet: Mittwoch, 25. September 2013 00:23 > >> An: [email protected] > >> Betreff: Re: Are bundles containing declerative services and > >> blueprint > possible? > >> > >> I can't see any reason all known osgi component frameworks > >> shouldn't > all work at once in one bundle. (e.g DS, IPOJO, Blueprint) > >> > >> Is there a thread dump for when this problem originally occurs? Do > >> you > know what state the bundle is in when blueprint gets in trouble? What > got the bundle into this state? > >> > >> If there's a deadlock between package admin and something else we > should fix it. (I recall running into some deadlocks like this a long > time ago, but don't recall the details). Please also try with DS > trunk as there are a _lot_ of changes even from 1.6.2 and any fix > would be made against trunk. > >> > >> thanks > >> david jencks > >> > >> On Sep 24, 2013, at 3:06 PM, Michael Täschner > >> <[email protected]> > wrote: > >> > >>> Hi Dirk, > >>> > >>>>> So we assume that the scr bundle activation cannot coexists with > >>>>> the > >>> blueprint container for the same bundle. Is this right? > >>> > >>> Yes, your assumption is correct. One bundle should be managed by > >>> one dependency injection implementation only. The DI is managed by > >>> the DI frameworks via extender pattern on startup and depending on > >>> which extender gets notified first (via bundlelistener) will try > >>> to > initialize the bundle. > >>> Therefore you will run into locks or IllegalStateException > >>> depending on the current order of extenders (blueprint, scr, ...) > >>> which runs > first. > >>> > >>> Your approach might work - but I don't think it is good style - if > >>> the "link" between the beans/components is realized via OSGi > >>> service registry (e.g. registering a service using blueprint and a > >>> reference in DS and vice > >>> versa) still I would strongly suggest sticking to one framework > >>> inside one bundle. > >>> > >>> The benefit of OSGi is the central service registry broker which > >>> allows providers and consumers to use their preferred DI approach > >>> inside their implementations independently from each other. > >>> > >>> Best Regards, > >>> Michael > >>> > >>> > >>> 2013/9/24 Rudolph, Dirk <[email protected]> > >>> > >>>> Hi all, > >>>> > >>>> > >>>> > >>>> in our project we make use of blueprint and declarative services. > >>>> Both of them are part of one bundle running on Apache Felix > >>>> (3.0.8.B006, CQ > >>>> Version) with Apache Aries 1.0.1 (blueprint, jpa) > >>>> > >>>> > >>>> > >>>> Now we noticed, that there are some non-deterministic > >>>> IllegalStateExceptions when we redeploy bundles and sometime > >>>> when we deploy bundles the first time. (stacktrace attached) > >>>> > >>>> > >>>> > >>>> 24.09.2013 12:12:12.990 *ERROR* [Blueprint Extender: 1] > >>>> org.apache.aries.blueprint.container.BlueprintContainerImpl > >>>> Unable to start blueprint container for bundle > >>>> ******************* > >>>> java.lang.IllegalStateException: Can only register services while > >>>> bundle is active or activating. > >>>> > >>>> at > >>>> org.apache.felix.framework.Felix.registerService(Felix.java:2824) > >>>> > >>>> at > >>>> org.apache.felix.framework.BundleContextImpl.registerService(Bund > >>>> leCo > >>>> ntextImpl.java:251) > >>>> > >>>> at > >>>> org.apache.felix.framework.BundleContextImpl.registerService(Bund > >>>> leCo > >>>> ntextImpl.java:229) > >>>> > >>>> at > >>>> org.apache.aries.jpa.container.context.impl.PersistenceContextMan > >>>> ager > >>>> .registerEM(PersistenceContextManager.java:286) > >>>> > >>>> at > >>>> org.apache.aries.jpa.container.context.impl.PersistenceContextMan > >>>> ager > >>>> .registerContext(PersistenceContextManager.java:200) > >>>> > >>>> at > >>>> org.apache.aries.jpa.container.context.impl.GlobalPersistenceManager. > >>>> registerContext(GlobalPersistenceManager.java:123) > >>>> > >>>> at > >>>> sun.reflect.GeneratedMethodAccessor398.invoke(Unknown > >>>> Source) > >>>> > >>>> at > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > >>>> Source) > >>>> > >>>> at java.lang.reflect.Method.invoke(Unknown Source) > >>>> > >>>> at > >>>> org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.ja > >>>> va:5 > >>>> 4) > >>>> > >>>> at > >>>> org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java > >>>> :119 > >>>> ) > >>>> > >>>> at $Proxy12.registerContext(Unknown Source) > >>>> > >>>> at > >>>> org.apache.aries.jpa.blueprint.aries.impl.NSHandler.decorate(NSHa > >>>> ndle > >>>> r.java:235) > >>>> > >>>> at > >>>> sun.reflect.GeneratedMethodAccessor136.invoke(Unknown > >>>> Source) > >>>> > >>>> at > >>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > >>>> Source) > >>>> > >>>> at java.lang.reflect.Method.invoke(Unknown Source) > >>>> > >>>> at > >>>> org.apache.aries.proxy.impl.ProxyHandler$1.invoke(ProxyHandler.ja > >>>> va:5 > >>>> 4) > >>>> > >>>> at > >>>> org.apache.aries.proxy.impl.ProxyHandler.invoke(ProxyHandler.java > >>>> :119 > >>>> ) > >>>> > >>>> at $Proxy9.decorate(Unknown Source) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.decorateCustomNode(Parse > >>>> r.ja > >>>> va:1273) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.handleCustomElements(Parser. > >>>> java:1263) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.parseBeanMetadata(Parser > >>>> .jav > >>>> a:601) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.parseBlueprintElement(Pa > >>>> rser > >>>> .java:393) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.ja > >>>> va:3 > >>>> 26) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.parser.Parser.populate(Parser.java:277 > >>>> ) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun > >>>> (Blu > >>>> eprintContainerImpl.java:315) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(B > >>>> luep > >>>> rintContainerImpl.java:261) > >>>> > >>>> at > >>>> java.util.concurrent.Executors$RunnableAdapter.call(Unknown > >>>> Source) > >>>> > >>>> at > >>>> java.util.concurrent.FutureTask$Sync.innerRun(Unknown > >>>> Source) > >>>> > >>>> at java.util.concurrent.FutureTask.run(Unknown > >>>> Source) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.container.ExecutorServiceWrapper.run(E > >>>> xecu > >>>> torServiceWrapper.java:106) > >>>> > >>>> at > >>>> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnab > >>>> le.r > >>>> un(DiscardableRunnable.java:48) > >>>> > >>>> at > >>>> java.util.concurrent.Executors$RunnableAdapter.call(Unknown > >>>> Source) > >>>> > >>>> at > >>>> java.util.concurrent.FutureTask$Sync.innerRun(Unknown > >>>> Source) > >>>> > >>>> at java.util.concurrent.FutureTask.run(Unknown > >>>> Source) > >>>> > >>>> at > >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. > >>>> access$201(Unknown > >>>> Source) > >>>> > >>>> at > >>>> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask. > >>>> run(Unknown > >>>> Source) > >>>> > >>>> at > >>>> java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > >>>> > >>>> at > >>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown > >>>> Source) > >>>> > >>>> at java.lang.Thread.run(Unknown Source) > >>>> > >>>> > >>>> > >>>> After a while of debugging we figured out that the service cannot > >>>> be registered because Felix fails to obtain the lock on the > >>>> bundle. The lock is hold by the Thread running the Apache Felix > >>>> BundleComponentActivator (FelixPackageAdmin). So we assume that > >>>> the scr bundle activation cannot coexists with the blueprint > >>>> container > for the same bundle. Is this right? > >>>> Would it be possible to trigger the blueprint container creation > >>>> after scr has been processed or vice versa? > >>>> > >>>> > >>>> > >>>> Thanks so far, > >>>> > >>>> > >>>> Dirk Rudolph > >>>> > >>>> > >>>> > >>>> > >>>> T-Systems Multimedia Solutions GmbH Organisationseinheit CCS Dirk > >>>> Rudolph Software-Entwicklung, OCJP > >>>> > >>>> Hausanschrift: Riesaer Straße 5, 01129 Dresden > >>>> Postanschrift: Postfach 10 02 24, 01072 Dresden > >>>> +49 351 2820-5363 (Tel) > >>>> E-Mail: [email protected] > >>>> <mailto:[email protected] > >>>>> > >>>> Internet: http://www.t-systems-mms.com > >>>> <http://www.t-systems-mms.de/> > >>>> > >>>> T-Systems Multimedia Solutions GmbH > >>>> > >>>> Aufsichtsrat: Klaus Werner (Vorsitzender) > >>>> > >>>> Geschäftsführung: Peter Klingenburg, Susanne Heger > >>>> > >>>> Handelsregister: Amtsgericht Dresden HRB 11433 > >>>> > >>>> Sitz der Gesellschaft: Dresden > >>>> > >>>> Ust-IdNr.: DE 811 807 949 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >> > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> <threaddump-bp.txt> > >> ------------------------------------------------------------------- > >> -- 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] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
