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