Hi David,
(sorry to do all this noise while you are releasing ...)
We are indeed using factory components; and today, I finally found and
fixed a cycle, using the Apache Service Diagnostic tool; and I'm going
further on but now I'm facing another problem which I did not have in the
scr 1.6.2.
So, I would like to discuss about this new problem with you before you redo
a release, in order to decide if this problem (if there is really one ?)
shall be addressed now or after the upcoming release ?
So, in our application, we are extensively using factory components
(@Component(factory=XXX")).
When we instantiate a factory component (using
ComponentFactory.newInstance()), We pass to the newInstance() method some
additional component properties which may also contain some target filters.
This allows to dynamically configure the filter of some References declared
in the factory component.
in the scr 1.6.2, this mechanism was working fine. But using trunk, this
does not work all the time. Some target filters seem to be correctly
configured, and some others are not (I'm not sure, actually, it's late ...).
So, it looks like sometimes, some target filters are not updated before
activating components ? or factory components ?
I'm not sure but this might be related to the old FELIX-3726.
Now, interestingly, I did the following patch and my application is now
working fine: In the AbstractComponentManager class, I systematically
update target filters, like this:
+++
src/main/java/org/apache/felix/scr/impl/manager/AbstractComponentManager.java
(working copy)
@@ -809,6 +809,7 @@
{
// Before creating the implementation object, we are going to
// test if all the mandatory dependencies are satisfied
+ updateTargets(getProperties());
if ( !verifyDependencyManagers() )
{
log( LogService.LOG_DEBUG, "Not all dependencies
satisfied, cannot activate", null );
Is this patch correct ? or may be it shall be done somewhere else ?
(may be we can address this later, after the release; I let you decide).
best regards;
/Pierre
On Tue, Oct 22, 2013 at 7:27 PM, David Jencks <[email protected]>wrote:
> Hi Pierre,
>
> Thanks for the additional checking.
>
> There are some changes in circular dependency checking for immediate
> components. Each component marks threads that are trying to get the
> service instance, and if the thread is already marked, this code is
> executed (SimpleComponentManager line 779):
>
> log( LogService.LOG_ERROR, "Circular reference detected,
> getService returning null", null );
> dumpThreads();
>
> So if this code is activated the result should be very obvious :-)
>
> I don't think this code can be activated by delayed or service factory
> components, because the ServiceRegistry will already have blocked the 2nd
> getService call on the same thread. You should get a message from the
> ServiceRegistry in this case. I think this code can only be activated by
> an immediate component where trying to fetch one of the reference services
> causes a loop back to the service being constructed.
>
> Is it possible that your circular dependencies involve factory components
> or service factory components?
>
> I think I'll start the release process and if you come up with anything
> more concrete before the vote concludes I'd be happy to stop and try to fix
> it.
>
> many thanks!
> david jencks
>
>
>
> On Oct 22, 2013, at 9:58 AM, Pierre De Rop <[email protected]> wrote:
>
> > Hi David,
> >
> > it's OK from my side, your last commit has fixed the NPE.
> >
> > thanks ! :-)
> >
> > Now, today, I did some more tests and I found another problem.
> > Unfortunately I did not have time to investigate. So perhaps we can go
> > ahead with a release, and later, if I really find something then I will
> get
> > back to the forum ... it's probably some kind of circular dependencies we
> > have in some of our product ... not sure for now.
> >
> > So, I wonder if the new upcoming SCR release is making some more checking
> > regarding cycle detection ? And does SCR log some warnings when it
> detects
> > some circular loops ?
> >
> > thanks;
> >
> > best regards;
> > /Pierre
> >
> >
> >
> > On Tue, Oct 22, 2013 at 12:11 AM, David Jencks <[email protected]
> >wrote:
> >
> >> Hi Pierre,
> >>
> >> I opened https://issues.apache.org/jira/browse/FELIX-4287 and committed
> >> what I think is a fix :-). This prompted me to clean up the mess of
> >> deactivate/dispose methods so that was a very good thing :-)
> >>
> >> I got my maven configuration straightened out so I can deploy snapshots,
> >> and that should be enough to deploy release candidates too.
> >>
> >> Could you check out the fix? I'll run some tests here too.
> >>
> >> many thanks!
> >> david jencks
> >>
> >>
> >> On Oct 21, 2013, at 1:11 AM, Pierre De Rop <[email protected]>
> wrote:
> >>
> >>> Hi David,
> >>>
> >>> I did some quick tests, and the trunk seems to work seamlessly in our
> our
> >>> DS based products.
> >>> Also checked that all tests are passing ok in scr maven tests.
> >>>
> >>> Just one thing that I noticed: In one of our products, I'm getting the
> >>> following exception, when stopping the framework (Ctrl-C from gogo
> >> shell):
> >>> I did not have time to investigate it but I copy/past it here, so you
> can
> >>> check it:
> >>>
> >>> 2013-10-21 09:39:49,862 [FelixStartLevel] ERROR
> >>> com.alcatel_lucent.as.service.composite.impl.CompositeManager - Error
> >>> processing task
> >>> java.lang.NullPointerException
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.BundleComponentActivator.unregisterComponentId(BundleComponentActivator.java:500)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.clear(AbstractComponentManager.java:1157)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.clear(SingleComponentManager.java:109)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:890)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:576)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:561)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.ComponentContextImpl$ComponentInstanceImpl.dispose(ComponentContextImpl.java:226)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.CompositeFactoryImpl$CompositeInstanceImpl$1.run(CompositeFactoryImpl.java:86)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.SerialExecutor.execute(SerialExecutor.java:36)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.CompositeManager.stop(CompositeManager.java:105)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> at
> >>>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>> at
> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>> at java.lang.reflect.Method.invoke(Method.java:601)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
> >>> at
> >>> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:338)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:170)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:907)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.deactivateInternal(AbstractComponentManager.java:855)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:945)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$SingleStaticCustomizer.removedService(DependencyManager.java:871)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1503)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1398)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1258)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1437)
> >>> 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:4401)
> >>> 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:151)
> >>> at
> >>>
> >>
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.CompositeAdminImpl$1.run(CompositeAdminImpl.java:75)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.SerialExecutor.execute(SerialExecutor.java:36)
> >>> at
> >>>
> >>
> com.alcatel_lucent.as.service.composite.impl.CompositeAdminImpl.stop(CompositeAdminImpl.java:66)
> >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >>> at
> >>>
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >>> at
> >>>
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >>> at java.lang.reflect.Method.invoke(Method.java:601)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.invokeMethod(BaseMethod.java:231)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod.access$500(BaseMethod.java:39)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.BaseMethod$Resolved.invoke(BaseMethod.java:624)
> >>> at
> >>> org.apache.felix.scr.impl.helper.BaseMethod.invoke(BaseMethod.java:508)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.helper.ActivateMethod.invoke(ActivateMethod.java:149)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.disposeImplementationObject(SingleComponentManager.java:338)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.deleteComponent(SingleComponentManager.java:170)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.doDeactivate(AbstractComponentManager.java:907)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.disposeInternal(AbstractComponentManager.java:889)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.manager.AbstractComponentManager.dispose(AbstractComponentManager.java:576)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.config.ConfigurableComponentHolder.disposeComponents(ConfigurableComponentHolder.java:421)
> >>> at
> >>>
> >>
> org.apache.felix.scr.impl.BundleComponentActivator.dispose(BundleComponentActivator.java:336)
> >>> at
> >>>
> org.apache.felix.scr.impl.Activator.disposeComponents(Activator.java:290)
> >>> at
> >> org.apache.felix.scr.impl.Activator.access$100(Activator.java:44)
> >>> at
> >> org.apache.felix.scr.impl.Activator$1.destroy(Activator.java:174)
> >>> at
> >>>
> >>
> org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:285)
> >>> at
> >>> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> >>> at
> >> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> >>> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> >>> at
> >>>
> >>
> org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:307)
> >>> at
> >>>
> >>
> org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:181)
> >>> at
> >>>
> >>
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:868)
> >>> at
> >>>
> >>
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:789)
> >>> at
> >>>
> >>
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:514)
> >>> at
> >> org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4385)
> >>> at org.apache.felix.framework.Felix.stopBundle(Felix.java:2508)
> >>> at
> >>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1297)
> >>> at
> >>>
> >>
> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:304)
> >>> at java.lang.Thread.run(Thread.java:722)
> >>>
> >>>
> >>> best regards;
> >>> /Pierre
> >>>
> >>> Le 20 oct. 2013 07:50, "David Jencks" <[email protected]> a
> écrit :
> >>>>
> >>>> I haven't found any new problems with DS recently and am running out
> of
> >>> refactoring and code cleanup ideas so I think it might be time to work
> >> on
> >>> releasing DS 1.8. If anyone wants to do any last minute testing or
> code
> >>> reviews that would be great. If nothing comes up I expect to suggest
> >>> starting the release process early next week.
> >>>>
> >>>> I'm not sure what the felix community usually does about release
> >>> managers. I'd be equally happy being the release manager or leaving it
> >> to
> >>> someone who has done it before. I think I don't currently have the
> >>> necessary nexus permissions to release, but this should be easy to fix.
> >>>>
> >>>> many thanks
> >>>> david jencks
> >>>>
> >>
> >>
>
>
