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(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] >
smime.p7s
Description: S/MIME cryptographic signature
