Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer;
  b=Khx7IWXuB2UI2uhP54bIvkR5rWUHKAjoEfJhzZheJWDs1U57wK2fIFbrksw7UJXbmKcUgf4oEnsxdv3gkRkun8QuN1hnrrytRRsXovLMBWSnc5bbM6k+LPKOY9VvY/foVwralbzoKn1NDlWcCZNJKD0DsyhvuDjNpnfOw9a3Tlo=
  ;
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1084)
Subject: Re: SCR could not obtain state lock after 5 seconds
From: David Jencks <david_jencks@yahoo.com>
In-Reply-To: 
 <CAGT3RROzAf6kc4hBSQGkEgfx_My4uFbT0iYf6qYTVN=k4AMKEw@mail.gmail.com>
Date: Thu, 6 Sep 2012 19:41:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <61F7297E-5A11-4EF0-AFEA-2BBB668397F7@yahoo.com>
References: 
 <CAGT3RRMT3PQMmwaH2DYaYuuJ1Cgz+aYWFtwODfLRUxLktKdD2A@mail.gmail.com>
 <ADDCB005-95D4-4813-85F3-9B694064CE9D@yahoo.com>
 <CAGT3RROCbq2jrO+h5FRoYHsw7SdkX7HOrnepnc5Vesmj1PCvuw@mail.gmail.com>
 <7B457C22-967F-486D-92FE-8D9FF59A3C61@yahoo.com>
 <CAGT3RRPPtjS1++c9oSVnMszBoKr=t1D1pEreTH-_YwYm__D15Q@mail.gmail.com>
 <A6DE7D9A-36C1-47E2-B7AE-D92FB29A50C4@yahoo.com>
 <078AC2F8-BC19-4675-8248-779C5D6C7F76@yahoo.com>
 <CAGT3RROP1=iFbSN0AGpkgkRZoHrRRmnqqCcD8Ev9dRs2nNJbPQ@mail.gmail.com>
 <CAGT3RRMOPJkcyJi2tSa6qGtszVcPQbATv+oojbc2svOma=9-mA@mail.gmail.com>
 <6C04A2F3-24C4-433B-B2B9-73761B45978E@yahoo.com>
 <CAGT3RRO8v222hvLS3cWkbFSLX+5_tHT3MTGcqaxbUa7uv=g3ig@mail.gmail.com>
 <CAGT3RRMJdj-sQW0bpOOT2y3e4_btnV+WFwdCjLW5NDqNJQ84aw@mail.gmail.com>
 <2FFE988D-6D0A-4BFC-A893-58C7488C772D@adobe.com>
 <CAGT3RRM=XZY809m9_Xf9A3rievZA_QW2QjdhJGDp6-jPhWMt3g@mail.gmail.com>
 <CAGT3RRNVUgKUNTAabrkeyR3S+oCENfasWzg3Kspk3hFBWA2nMw@mail.gmail.com>
 <7E07E4E3-856E-437C-BCAE-D3987B8CB86B@yahoo.com> <CAGT3RRMoCTRF7xap4JHT
 1xvfEbN4mxk38XF4gb7cs551Kk0rkQ@mail.gmail.com>
 <A0DC5597-54DD-4823-9919-2499252DBCC4@yahoo.com>
 <CAGT3RROzAf6kc4hBSQGkEgfx_My4uFbT0iYf6qYTVN=k4AMKEw@mail.gmail.com>
To: dev@felix.apache.org

I opened https://issues.apache.org/jira/browse/FELIX-3658 for the first =
problem and think I have a simple fix.

For the second problem, it looks like whenever you disable a component =
its component id is set to -1.   So the problem must be something with =
re-enabling it.  I haven't looked further.

thanks!
david jencks

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

> Hi David,
>=20
> 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.
>=20
> here it is:
>=20
> When you have a delayed component "A", which is activated because =
another
> component "B" has a dependency on it (dynamic, cardinality=3D0..N), =
then when
> you manually disable "A" (from the "scr:disable" shell commandl), you =
then
> get an "java.lang.IllegalStateException: ungetServiceDisabled" error:
>=20
> 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=3DINFO,
> T=3DThread[Thread-1,5,main], M=3DServiceEvent UNREGISTERING
>=20
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager$State.ungetServ=
ice(AbstractComponentManager.java:1308)
>       at
> =
org.apache.felix.scr.impl.manager.ImmediateComponentManager.ungetService(I=
mmediateComponentManager.java:693)
>       at
> =
org.apache.felix.framework.ServiceRegistrationImpl.ungetFactoryUnchecked(S=
erviceRegistrationImpl.java:349)
>       at
> =
org.apache.felix.framework.ServiceRegistrationImpl.ungetService(ServiceReg=
istrationImpl.java:258)
>       at
> =
org.apache.felix.framework.ServiceRegistry.ungetService(ServiceRegistry.ja=
va:389)
>       at =
org.apache.felix.framework.Felix.ungetService(Felix.java:3432)
>       at
> =
org.apache.felix.framework.BundleContextImpl.ungetService(BundleContextImp=
l.java:486)
>       at
> =
org.apache.felix.scr.impl.manager.DependencyManager.ungetService(Dependenc=
yManager.java:913)
>       at
> =
org.apache.felix.scr.impl.manager.DependencyManager.serviceRemoved(Depende=
ncyManager.java:480)
>       at
> =
org.apache.felix.scr.impl.manager.DependencyManager.serviceChanged(Depende=
ncyManager.java:250)
>       at
> =
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallb=
ack(EventDispatcher.java:932)
>       at
> =
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(Event=
Dispatcher.java:793)
>       at
> =
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDisp=
atcher.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(ServiceRegist=
ry.java:148)
>       at
> =
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegis=
trationImpl.java:127)
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager.unregisterCompo=
nentService(AbstractComponentManager.java:759)
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager$State.doDeactiv=
ate(AbstractComponentManager.java:1354)
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager$Disabled.deacti=
vate(AbstractComponentManager.java:1428)
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInter=
nal(AbstractComponentManager.java:619)
>       at
> =
org.apache.felix.scr.impl.manager.AbstractComponentManager$2.run(AbstractC=
omponentManager.java:419)
>       at
> =
org.apache.felix.scr.impl.ComponentActorThread.run(ComponentActorThread.ja=
va:98)
>       at java.lang.Thread.run(Thread.java:662)
> stop
>=20
> 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.
>=20
>=20
> Are we talking about the same kind of ServiceFactory problem or should =
I
> create a separate jira issue ?
>=20
> regards;
> /pierre
>=20
>=20
>=20
> On Thu, Sep 6, 2012 at 6:31 PM, David Jencks <david_jencks@yahoo.com> =
wrote:
>=20
>> Looking forward to any review :-)
>>=20
>> I've found an additional problem with ServiceFactory components that =
I'm
>> trying to fix....
>>=20
>> david jencks
>>=20
>> On Sep 6, 2012, at 2:54 AM, Pierre De Rop wrote:
>>=20
>>> Hi David,
>>>=20
>>> I'm happy to see that the test helped, and it seems that fixing this
>> issue was not an easy task,
>>> congratulation !
>>>=20
>>> 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.
>>>=20
>>> So, from my side, I confirm, the testcase is now passing.
>>>=20
>>> 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=3Dwarn, and it is also =
passing OK.
>>>=20
>>> So, now, I will run again my nightly integration tests, in order to =
do
>> more validation.
>>>=20
>>> thanks again.
>>> /pierre
>>>=20
>>> 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).
>>>=20
>>> The itest was extremely helpful :-)
>>>=20
>>> 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?
>>>=20
>>> 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.
>>>=20
>>> Please try out the changes and let me know if you find more =
problems!
>>>=20
>>> thanks
>>> david jencks
>>>=20
>>> On Sep 2, 2012, at 11:02 PM, David Jencks wrote:
>>>=20
>>>> Excellent!
>>>>=20
>>>> 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 :-)
>>>>=20
>>>> Looking forward to trying out your test case...
>>>>=20
>>>> david jencks
>>>>=20
>>>> On Sep 2, 2012, at 6:58 AM, Pierre De Rop wrote:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> I committed in revision 1379968 a (candidate) integration test, =
which
>> seems
>>>>> to reproduce the problem.
>>>>> Hope it will help.
>>>>>=20
>>>>> regards;
>>>>> /pierre
>>>>>=20
>>>>> On Fri, Aug 31, 2012 at 2:08 PM, Pierre De Rop <
>> pierre.derop@gmail.com>wrote:
>>>>>=20
>>>>>> Hi Felix,
>>>>>>=20
>>>>>> ok, I will try to do it.
>>>>>>=20
>>>>>> regards;
>>>>>> /pierre
>>>>>>=20
>>>>>> On Fri, Aug 31, 2012 at 1:58 PM, Felix Meschberger <
>> fmeschbe@adobe.com>wrote:
>>>>>>=20
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Am 31.08.2012 um 02:20 schrieb Pierre De Rop:
>>>>>>>=20
>>>>>>>> Hi David,
>>>>>>>>=20
>>>>>>>> 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 ...
>>>>>>>>=20
>>>>>>>> I will create a jira issue and will attach the sample to it.
>>>>>>>=20
>>>>>>> Thanks alot.
>>>>>>>=20
>>>>>>> Would be great if we could integrate that sample as an =
integration
>> test
>>>>>>> case.
>>>>>>>=20
>>>>>>> Regards
>>>>>>> Felix
>>>>>>>=20
>>>>>>>> ...
>>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>=20
>>>=20
>>>=20
>>=20
>>=20