felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [DS] time for 1.8 release?
Date Fri, 25 Oct 2013 07:11:32 GMT
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 <pierre.derop@gmail.com> 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 <david_jencks@yahoo.com>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 <pierre.derop@gmail.com> 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 <david_jencks@yahoo.com
>>> 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 <pierre.derop@gmail.com>
>> 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 <david_jencks@yahoo.com
>>>>> 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 <pierre.derop@gmail.com>
>>>> 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" <david_jencks@yahoo.com>
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
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>> 
>>>> 
>> 
>> 


Mime
View raw message