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 12:39:04 GMT
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.

-----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(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_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(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.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