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 <[email protected]> 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 <[email protected]>
> 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 <
> [email protected]>wrote:
> > >>
> > >>> Hi Felix,
> > >>>
> > >>> ok, I will try to do it.
> > >>>
> > >>> regards;
> > >>> /pierre
> > >>>
> > >>> On Fri, Aug 31, 2012 at 1:58 PM, Felix Meschberger <
> [email protected]>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
> > >>>>
> > >>>>> ...
> > >>>>
> > >>>
> > >>>
> > >
> >
> >
>
>
