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 > >>>>>> > >>>> > >>>> > >> > >> > >
