That's right. I also think the issue is related to FELIX-3067. Should I describe the issue their again (just for completeness)?
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(BundleContextImpl.java:251) > at > org.apache.felix.framework.BundleContextImpl.registerService(BundleContextImpl.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(BundleCo >>> ntextImpl.java:251) >>> >>> at >>> org.apache.felix.framework.BundleContextImpl.registerService(BundleCo >>> ntextImpl.java:229) >>> >>> at >>> org.apache.aries.jpa.container.context.impl.PersistenceContextManager >>> .registerEM(PersistenceContextManager.java:286) >>> >>> at >>> org.apache.aries.jpa.container.context.impl.PersistenceContextManager >>> .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.java: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(NSHandle >>> 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.java: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(Parser.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(Parser >>> .java:393) >>> >>> at >>> org.apache.aries.blueprint.parser.Parser.loadComponents(Parser.java: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(Bluep >>> 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(Execu >>> torServiceWrapper.java:106) >>> >>> at >>> org.apache.aries.blueprint.utils.threading.impl.DiscardableRunnable.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]
