felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rudolph, Dirk" <Dirk.Rudo...@t-systems.com>
Subject AW: Are bundles containing declerative services and blueprint possible?
Date Wed, 25 Sep 2013 13:50:39 GMT
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:njbartlett@gmail.com] 
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
<Dirk.Rudolph@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:fmeschbe@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:fmeschbe@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(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:david_jencks@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.taeschner@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.Rudolph@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(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: Dirk.Rudolph@t-systems.com 
> >>>> <mailto:mDirk.Rudolph@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-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >> <threaddump-bp.txt>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Mime
View raw message