On Wed, Sep 25, 2013 at 1:39 PM, Rudolph, Dirk <dirk.rudo...@t-systems.com>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:fmesc...@adobe.com] > Gesendet: Mittwoch, 25. September 2013 11:07 > An: users@felix.apache.org > 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:fmesc...@adobe.com] > > Gesendet: Mittwoch, 25. September 2013 10:01 > > An: users@felix.apache.org > > 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:david_jen...@yahoo.com] > >> Gesendet: Mittwoch, 25. September 2013 00:23 > >> An: users@felix.apache.org > >> 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 <m.taesch...@gmail.com> > 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 <dirk.rudo...@t-systems.com> > >>> > >>>> 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: dirk.rudo...@t-systems.com > >>>> <mailto:mdirk.rudo...@t-systems-mms.com > >>>>> > >>>> 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: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > >> > >> <threaddump-bp.txt> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > >> For additional commands, e-mail: users-h...@felix.apache.org > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > > For additional commands, e-mail: users-h...@felix.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > >
