Hi Pierre, You are so good at writing useful tests!!
I found a place to call setTargets(getProperties()) from inside ComponentFactoryImpl that would have fewer side effects. Could you see if this makes your actual applications work properly? I'm uploading a snapshot. many thanks david jencks On Oct 24, 2013, at 6:17 AM, Pierre De Rop <[email protected]> wrote: > Hi David, > > Since this application is complex, I'm not able to provide logs because > there are hundreds of components involved which are not mine, and for now, > I'm not able to diagnose the problem. > > But I have created FELIX-4290, and joined to it an integration test which > seems to reproduce the kind of problem I think I'm having in my > application. I also joined the proposed patch. > > I did not have time to test the patch you suggested regarding the > SingleComponentManager.reconfigure method, so let's continue to investigate > using the jira issue and the test I attached to it. > > Thanks; > > /Pierre > > > On Thu, Oct 24, 2013 at 12:27 AM, David Jencks <[email protected]>wrote: > >> Hi Pierre, >> >> I believe you that this code path doesn't work :-) >> >> I think there should be a less invasive way to fix this. By any chance >> can you get a debug-enabled log from when this problem occurs? It would >> help confirm my suspicions of what might be missing. >> >> FWIW I suspect SingleComponentManager.reconfigure is missing a check for >> m_factoryProperties here (line 561): >> >> // nothing to do if there is no configuration (see FELIX-714) >> if ( configuration == null && m_configurationProperties == >> null ) >> { >> log( LogService.LOG_DEBUG, "No configuration provided (or >> deleted), nothing to do", null ); >> return; >> } >> >> Unless we can't figure anything out for sure I'd prefer to fix this before >> the release. >> >> thanks >> david jencks >> >> On Oct 23, 2013, at 3:09 PM, Pierre De Rop <[email protected]> wrote: >> >>> 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 >>>>>>>> >>>>>> >>>>>> >>>> >>>> >> >>
