felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: SCR could not obtain state lock after 5 seconds
Date Thu, 06 Sep 2012 21:16:20 GMT
Hi Pierre..... so many problems :-)

These are 2 unrelated problems, to each other and to the problem I found.

I sure wonder why we didn't see these before....

thanks
david jencks

On Sep 6, 2012, at 1:22 PM, Pierre De Rop wrote:

> Hi David,
> 
> I don't know if it's related to the problem you are talking about, but I
> just noticed a problem which might also be related to ServiceFactory.
> 
> here it is:
> 
> When you have a delayed component "A", which is activated because another
> component "B" has a dependency on it (dynamic, cardinality=0..N), then when
> you manually disable "A" (from the "scr:disable" shell commandl), you then
> get an "java.lang.IllegalStateException: ungetServiceDisabled" error:
> 
> g! scr:list
>   Id   State          Name
> [   2] [active       ] test.disable.A
> [   0] [active       ] test.disable.B
> [   1] [active       ] test.disable.LogTracker
> g! scr:disable 2
> Component test.disable.A disabled
> g! ERROR: Bundle test.scr.deadlock2 [9] ServiceRegistrationImpl: Error
> ungetting service. (java.lang.IllegalStateException: ungetServiceDisabled)
> java.lang.IllegalStateException: ungetServiceDisabledLogTracker: L=INFO,
> T=Thread[Thread-1,5,main], M=ServiceEvent UNREGISTERING
> 
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$State.ungetService(AbstractComponentManager.java:1308)
>        at
> org.apache.felix.scr.impl.manager.ImmediateComponentManager.ungetService(ImmediateComponentManager.java:693)
>        at
> org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(ServiceRegistrationImpl.java:349)
>        at
> org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceRegistrationImpl.java:258)
>        at
> org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.java:389)
>        at org.apache.felix.framework.Felix.ungetService(Felix.java:3432)
>        at
> org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImpl.java:486)
>        at
> org.apache.felix.scr.impl.manager.DependencyManager.ungetService(DependencyManager.java:913)
>        at
> org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(DependencyManager.java:480)
>        at
> org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(DependencyManager.java:250)
>        at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
>        at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
>        at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
>        at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
>        at org.apache.felix.framework.Felix.access$000(Felix.java:74)
>        at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
>        at
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
>        at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterComponentService(AbstractComponentManager.java:759)
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactivate(AbstractComponentManager.java:1354)
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$Disabled.deactivate(AbstractComponentManager.java:1428)
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:619)
>        at
> org.apache.felix.scr.impl.manager.AbstractComponentManager$2.run(AbstractComponentManager.java:419)
>        at
> org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.java:98)
>        at java.lang.Thread.run(Thread.java:662)
> stop
> 
> I also noticed that when you disable an immediate component, then we have
> no exceptions, but under the shell, the component id is then set to "-1",
> and you then can't re-enable it anymore, but this is another kind of
> problem, I think.
> 
> 
> Are we talking about the same kind of ServiceFactory problem or should I
> create a separate jira issue ?
> 
> regards;
> /pierre
> 
> 
> 
> On Thu, Sep 6, 2012 at 6:31 PM, David Jencks <david_jencks@yahoo.com> wrote:
> 
>> Looking forward to any review :-)
>> 
>> I've found an additional problem with ServiceFactory components that I'm
>> trying to fix....
>> 
>> david jencks
>> 
>> On Sep 6, 2012, at 2:54 AM, Pierre De Rop wrote:
>> 
>>> Hi David,
>>> 
>>> I'm happy to see that the test helped, and it seems that fixing this
>> issue was not an easy task,
>>> congratulation !
>>> 
>>> For now, I can't reply to your question about the bind/unbind/updated
>> method, because I have not yet fully reviewed your fix, but this is an
>> excellent exercise for me and I will take time to understand the changes
>> you made.
>>> 
>>> So, from my side, I confirm, the testcase is now passing.
>>> 
>>> However, I have a minor remark: the felix log level is now forced to
>> debug: see  systemProperty( "ds.loglevel" ).value( "debug" ) in the
>> ComponentTestBase class), and I think that it might be better to run the
>> concurrent test in warn level, as before, because debug logs might reduce
>> the chances to reproduce any potential concurrency issues ... Anyway, I
>> tried to run the testcase with ds.loglevel=warn, and it is also passing OK.
>>> 
>>> So, now, I will run again my nightly integration tests, in order to do
>> more validation.
>>> 
>>> thanks again.
>>> /pierre
>>> 
>>> On Thu, Sep 6, 2012 at 12:23 AM, David Jencks <david_jencks@yahoo.com>
>> wrote:
>>> I finally got everything to work :-) (see caveats in the bug report).
>>> 
>>> The itest was extremely helpful :-)
>>> 
>>> One of the changes I made that perhaps could use some review is that
>> once the bind/unbind/updated methods are set, they are never cleared from
>> the dependency manager.  I don't think this is really a problem.  Have I
>> missed something?
>>> 
>>> We talked a bit a while ago about sharing the bind/unbind/updated
>> methods among dependency managers and trying to make them look up the
>> methods only once.  I've moved most of the dependencyManager state out of
>> the dependency managers, so we might be able to move the rest of the state
>> out and share the dependency managers among all the component managers for
>> the same component.  This might be better post 1.8 however.
>>> 
>>> Please try out the changes and let me know if you find more problems!
>>> 
>>> thanks
>>> david jencks
>>> 
>>> On Sep 2, 2012, at 11:02 PM, David Jencks wrote:
>>> 
>>>> Excellent!
>>>> 
>>>> I've been working on my idea how to fix this, but I'm still at the
>> stage of getting the existing integration tests to pass.  At least some
>> stuff works :-)
>>>> 
>>>> Looking forward to trying out your test case...
>>>> 
>>>> david jencks
>>>> 
>>>> On Sep 2, 2012, at 6:58 AM, Pierre De Rop wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I committed in revision 1379968 a (candidate) integration test, which
>> seems
>>>>> to reproduce the problem.
>>>>> Hope it will help.
>>>>> 
>>>>> regards;
>>>>> /pierre
>>>>> 
>>>>> On Fri, Aug 31, 2012 at 2:08 PM, Pierre De Rop <
>> pierre.derop@gmail.com>wrote:
>>>>> 
>>>>>> Hi Felix,
>>>>>> 
>>>>>> ok, I will try to do it.
>>>>>> 
>>>>>> regards;
>>>>>> /pierre
>>>>>> 
>>>>>> On Fri, Aug 31, 2012 at 1:58 PM, Felix Meschberger <
>> fmeschbe@adobe.com>wrote:
>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> Am 31.08.2012 um 02:20 schrieb Pierre De Rop:
>>>>>>> 
>>>>>>>> Hi David,
>>>>>>>> 
>>>>>>>> I have progressed and it seems that now I can reproduce the
>> problem,
>>>>>>> using
>>>>>>>> a sample code.
>>>>>>>> It's a sample inspired from the scenario that you suggested
in your
>>>>>>>> previous post, with A > B > C, and A > C ...
>>>>>>>> 
>>>>>>>> I will create a jira issue and will attach the sample to
it.
>>>>>>> 
>>>>>>> Thanks alot.
>>>>>>> 
>>>>>>> Would be great if we could integrate that sample as an integration
>> test
>>>>>>> case.
>>>>>>> 
>>>>>>> Regards
>>>>>>> Felix
>>>>>>> 
>>>>>>>> ...
>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>> 
>>> 
>> 
>> 


Mime
View raw message