You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2013/10/20 07:50:04 UTC
[DS] time for 1.8 release?
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
Re: [DS] time for 1.8 release?
Posted by Felix Meschberger <fm...@adobe.com>.
FYI: configadmin 1.8 is in central (just checked)
Thanks
Felix
—
Felix Meschberger | Principal Scientist | Adobe
Am 29.10.2013 um 00:13 schrieb David Jencks <da...@yahoo.com>:
> Pierre,
>
> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the problems I found (for 2). I don't see the OOM often enough to have any confidence that anything I do would actually fix it, so I'm inclined to do nothing. Is that OK with you?
>
> Unless you can find some more problems :-) I'm planning to try another release when the config admin 1.8 gets to maven central. I'm going to update the pom to normally run against the CA 1.8 version supporting R5 and change the profile so running against R4 requires specifying profiles explicitly.
>
> thanks again!
> david jencks
>
> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com> wrote:
>
>> Hi Pierre,
>>
>> Much better to find these problems before a release than just after!
>>
>> I saw an OOM once recently but haven't been able to reproduce it.
>>
>> I'm looking into the NPE. I think I see the timing hole it is using but need to think about it some more.
>>
>> many thanks!
>> david jencks
>>
>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>
>>> Hi David,
>>>
>>> Looking at our configurator component we are currently using (but we will fix it in order to use the multi-location "?"), I see this:
>>>
>>> void configure(String pid, Dictionary pidConf) {
>>> Configuration config = getConfiguration(_pid, null);
>>> if (config.getBundleLocation() != null) {
>>> config.setBundleLocation(null);
>>> }
>>> config.update(pidConf);
>>> }
>>>
>>> So I believe that you are getting a null configuration because there is a short window between the setBundleLocation(null) (at this point, the configuration is null) and the config.update(pidConf) call ...
>>>
>>> So, the good news is that I'm not having anymore some NPE using your latest commits :-) and I think our application is now fully operational.
>>>
>>> but ... (please don't start to abominate me ) now, in order to do a final check, I restarted the integration tests and there is still two problems:
>>>
>>> 1) I'm sometimes getting some out of memory errors: this is probably caused by the ComponentConcurrencyTest/Felix3680Test tests, which are currently configured in DEBUG mode ?
>>>
>>> 2) I ran the tests two times, and the second time, I got this exception with the failing
>>> Felix3680_2Test:
>>>
>>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test) Time elapsed: 36.597 sec <<< ERROR!
>>> java.lang.NullPointerException
>>> at org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>>> at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>>> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>>> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>>> 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:4260)
>>> 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:148)
>>> at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>>> at org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>> at java.lang.Thread.run(Thread.java:722)
>>>
>>> Are you also getting this exception ?
>>>
>>> thanks
>>>
>>> /Pierre
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com> wrote:
>>> Hi PIerre,
>>>
>>> Looking at the CA spec it looks like CA is supposed to send out CM_LOCATION_CHANGED events even before any properties are set when setBundleLocation is called. I added some code to ignore these events. Note that DS is "reserving" the configurations for (one of) the component(s) that will be consuming them by calling getConfiguration(pid).
>>>
>>> I do wonder how the location to something non-null on your configurations before the properties are set.
>>>
>>> Waiting for the next bug :-)
>>>
>>> thanks
>>> david jencks
>>>
>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>>
>>>> Hello David,
>>>>
>>>> The code we are using to configure our components is old, at at the time we wrote it, configadmin was not supporting multi-location. But I do agree, we can now use the "?" multi-location.
>>>>
>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
>>>>
>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent: pid=sipagent) ERROR osgi - [43] Unexpected problem delivering configuration event to [org.osgi.service.cm.ConfigurationListener, id=102, bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>
>>>> java.lang.NullPointerException
>>>> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>> at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>>>> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>> at java.lang.Thread.run(Thread.java:722)
>>>>
>>>>
>>>> I'm not sure, but it seems that ConfigAdmin is providing a null dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a normal behavior ?
>>>>
>>>> This is strange; perhaps I shall start a new integration test ?
>>>>
>>>> /Pierre
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com> wrote:
>>>> Hi Pierre,
>>>>
>>>> This pointed out a logic error I introduced for Felix 3651. I opened https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found which I think explains the NPE. Could you check this?
>>>>
>>>> Could I ask what you are trying to do by setting the bundleLocation to null? If you want to allow any bundle to receive the configuration you could use multi-location support and set the location to "?" With the code you have now, if the configuration is already in use by a DS component, the location changed event will result in the bundle location being reset back to what it was.
>>>>
>>>> thanks!
>>>> david jencks
>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> thanks; The fix is fixing the problem :-)
>>>>>
>>>>> but ... there's now a new different problem: i'm now sometimes getting this
>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>>>>>
>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
>>>>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>
>>>>> java.lang.NullPointerException
>>>>> at
>>>>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>> at
>>>>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>> at
>>>>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>>>>> at
>>>>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>> at
>>>>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>
>>>>> Perhaps a new jira issue shall be opened ?
>>>>>
>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>>>>> application, we populate configuration admin by doing something like this:
>>>>>
>>>>> Configuration cfg = cm.getConfiguration(pid, null)
>>>>> if (config.getBundleLocation() != null) {
>>>>> config.setBundleLocation(null);
>>>>> }
>>>>>
>>>>> The setBundleLocation(null) is probably useless, but this leads to a
>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
>>>>>> 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 <pi...@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 <pi...@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
>>>>>>>>>
>>>>
>>>>
>>>
>>>
>>
>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hello David,
Congratulations: no more "timeount on latch" errors, our application is
now starting seamlessly, and tests are all passing OK:
Results :
Tests run: 104, Failures: 0, Errors: 0, Skipped: 0
+1 !
/Pierre
On Wed, Oct 30, 2013 at 10:01 AM, David Jencks <da...@yahoo.com>wrote:
> Hi Pierre,
>
> I think I see what's going on and I wrote a test case for my theory and
> fixed it. Can you try again?
>
> many thanks!
> david jencks
>
> On Oct 29, 2013, at 4:00 PM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hi David,
> >
> > no, I did not notice the ERROR message you are mentioning.
> > (see the full logs in stacktrace2.log which I juste attached in the
> issue).
> >
> > Please forget my comment about the thread dump in WARN. I did not realize
> > that it was intentional to log it in DEBUG.
> >
> > regards;
> > /Pierre
> >
> >
> > On Tue, Oct 29, 2013 at 6:40 PM, David Jencks <david_jencks@yahoo.com
> >wrote:
> >
> >> HI Pierre,
> >>
> >> Do you by any chance see a log message at ERROR level like
> >>
> >> Cannot create component instance due to failure to bind reference {0}
> >>
> >> shortly before the timeout message?
> >>
> >> I'm not sure if it's a good idea to dump the threads at WARN. If you
> >> think it is I'll change it. Some people get upset if the logs are too
> long
> >> :-)
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >> On Oct 29, 2013, at 8:46 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >>
> >>> yes David, consistently. but I don't see stacktraces.
> >>>
> >>> Now, looking at the code, I see that this stacktrace is logged in
> DEBUG:
> >>>
> >>> final void dumpThreads()
> >>> {
> >>> try
> >>> {
> >>> String dump = new ThreadDump().call();
> >>> log( LogService.LOG_DEBUG, dump, null );
> >>>
> >>> So, I will activate DEBUG and provide the stacktrace.
> >>>
> >>> But is this a bug to log this stacktrace in DEBUG ?
> >>> I mean: should it be logged in WARN, instead of DEBUG ?
> >>>
> >>> /pierre
> >>>
> >>>
> >>> On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <david_jencks@yahoo.com
> >>> wrote:
> >>>
> >>>> Hi Pierre,
> >>>>
> >>>> I think there should be a thread dump in the log to go with this
> >> message.
> >>>> If there is could you send it to me or attach it to FELIX-4297?
> >>>>
> >>>> Does this happen consistently?
> >>>>
> >>>> many thanks
> >>>> david jencks
> >>>>
> >>>> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hi David;
> >>>>>
> >>>>> 1) Every integration tests are passing OK.
> >>>>>
> >>>>> Regarding the OOM, I believe that the out of memory is likely to be
> >> cause
> >>>>> by the following load tests, which are running in DEBUG mode:
> >>>>>
> >>>>>
> >>>>
> >>
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> >>>>> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
> >>>>> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
> >>>>>
> >>>>>
> >>>>> So, I just added this in each files (in static initializers):
> >>>>>
> >>>>> DS_LOGLEVEL = "warn";
> >>>>>
> >>>>> And I have no more OOM, with this nice test result message:
> >>>>>
> >>>>> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
> >>>>> [INFO] BUILD SUCCESS
> >>>>>
> >>>>>
> >>>>>
> >>>>> 2) Now, I did again a non regression tests with our applications, and
> >> I'm
> >>>>> seeing a new WARN message (but it does not seem to prevent the
> >>>> application
> >>>>> to be correctly initialized: all components are in the end
> satisfied):
> >>>>>
> >>>>> (if you believe that it's now time to release, then you can go ahead,
> >> and
> >>>>> we'll then investigate this new issue after the release ... I let you
> >>>>> decide)
> >>>>>
> >>>>> ->
> >>>>>
> >>>>> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
> >>>>> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
> >>>>> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)]
> >> DependencyManager
> >>>> :
> >>>>> invokeBindMethod : timeout on open latch newtcpprocessor
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> kind regards;
> >>>>> /Pierre
> >>>>>
> >>>>>
> >>>>> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <
> david_jencks@yahoo.com
> >>>>> wrote:
> >>>>>
> >>>>>> Pierre,
> >>>>>>
> >>>>>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed
> >> the
> >>>>>> problems I found (for 2). I don't see the OOM often enough to have
> >> any
> >>>>>> confidence that anything I do would actually fix it, so I'm inclined
> >> to
> >>>> do
> >>>>>> nothing. Is that OK with you?
> >>>>>>
> >>>>>> Unless you can find some more problems :-) I'm planning to try
> >> another
> >>>>>> release when the config admin 1.8 gets to maven central. I'm going
> to
> >>>>>> update the pom to normally run against the CA 1.8 version supporting
> >> R5
> >>>> and
> >>>>>> change the profile so running against R4 requires specifying
> profiles
> >>>>>> explicitly.
> >>>>>>
> >>>>>> thanks again!
> >>>>>> david jencks
> >>>>>>
> >>>>>> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hi Pierre,
> >>>>>>>
> >>>>>>> Much better to find these problems before a release than just
> after!
> >>>>>>>
> >>>>>>> I saw an OOM once recently but haven't been able to reproduce it.
> >>>>>>>
> >>>>>>> I'm looking into the NPE. I think I see the timing hole it is
> using
> >>>> but
> >>>>>> need to think about it some more.
> >>>>>>>
> >>>>>>> many thanks!
> >>>>>>> david jencks
> >>>>>>>
> >>>>>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pierre.derop@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hi David,
> >>>>>>>>
> >>>>>>>> Looking at our configurator component we are currently using (but
> we
> >>>>>> will fix it in order to use the multi-location "?"), I see this:
> >>>>>>>>
> >>>>>>>> void configure(String pid, Dictionary pidConf) {
> >>>>>>>> Configuration config = getConfiguration(_pid, null);
> >>>>>>>> if (config.getBundleLocation() != null) {
> >>>>>>>> config.setBundleLocation(null);
> >>>>>>>> }
> >>>>>>>> config.update(pidConf);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> So I believe that you are getting a null configuration because
> there
> >>>> is
> >>>>>> a short window between the setBundleLocation(null) (at this point,
> the
> >>>>>> configuration is null) and the config.update(pidConf) call ...
> >>>>>>>>
> >>>>>>>> So, the good news is that I'm not having anymore some NPE using
> your
> >>>>>> latest commits :-) and I think our application is now fully
> >> operational.
> >>>>>>>>
> >>>>>>>> but ... (please don't start to abominate me ) now, in order to
> do a
> >>>>>> final check, I restarted the integration tests and there is still
> two
> >>>>>> problems:
> >>>>>>>>
> >>>>>>>> 1) I'm sometimes getting some out of memory errors: this is
> probably
> >>>>>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which
> are
> >>>>>> currently configured in DEBUG mode ?
> >>>>>>>>
> >>>>>>>> 2) I ran the tests two times, and the second time, I got this
> >>>> exception
> >>>>>> with the failing
> >>>>>>>> Felix3680_2Test:
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>
> >>
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
> >>>>>> Time elapsed: 36.597 sec <<< ERROR!
> >>>>>>>> java.lang.NullPointerException
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> >>>>>>>> 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:4260)
> >>>>>>>> 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:148)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>>>>> at
> >>>>>>
> >>>>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>>>
> >>>>>>>> Are you also getting this exception ?
> >>>>>>>>
> >>>>>>>> thanks
> >>>>>>>>
> >>>>>>>> /Pierre
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <
> >> david_jencks@yahoo.com
> >>>>>
> >>>>>> wrote:
> >>>>>>>> Hi PIerre,
> >>>>>>>>
> >>>>>>>> Looking at the CA spec it looks like CA is supposed to send out
> >>>>>> CM_LOCATION_CHANGED events even before any properties are set when
> >>>>>> setBundleLocation is called. I added some code to ignore these
> >> events.
> >>>>>> Note that DS is "reserving" the configurations for (one of) the
> >>>>>> component(s) that will be consuming them by calling
> >>>> getConfiguration(pid).
> >>>>>>>>
> >>>>>>>> I do wonder how the location to something non-null on your
> >>>>>> configurations before the properties are set.
> >>>>>>>>
> >>>>>>>> Waiting for the next bug :-)
> >>>>>>>>
> >>>>>>>> thanks
> >>>>>>>> david jencks
> >>>>>>>>
> >>>>>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <
> pierre.derop@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Hello David,
> >>>>>>>>>
> >>>>>>>>> The code we are using to configure our components is old, at at
> the
> >>>>>> time we wrote it, configadmin was not supporting multi-location.
> But I
> >>>> do
> >>>>>> agree, we can now use the "?" multi-location.
> >>>>>>>>>
> >>>>>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
> >>>>>> always):
> >>>>>>>>>
> >>>>>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire
> >> ConfigurationEvent:
> >>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
> >>>> id=102,
> >>>>>>
> >>>>
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>>>>>
> >>>>>>>>> java.lang.NullPointerException
> >>>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> >>>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>>>>>> at
> >>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>>>>>> at
> >>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
> >>>>>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if
> correct,
> >>>> then
> >>>>>> Is this a normal behavior ?
> >>>>>>>>>
> >>>>>>>>> This is strange; perhaps I shall start a new integration test ?
> >>>>>>>>>
> >>>>>>>>> /Pierre
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
> >>>> david_jencks@yahoo.com>
> >>>>>> wrote:
> >>>>>>>>> Hi Pierre,
> >>>>>>>>>
> >>>>>>>>> This pointed out a logic error I introduced for Felix 3651. I
> >> opened
> >>>>>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the
> error
> >> I
> >>>>>> found which I think explains the NPE. Could you check this?
> >>>>>>>>>
> >>>>>>>>> Could I ask what you are trying to do by setting the
> bundleLocation
> >>>> to
> >>>>>> null? If you want to allow any bundle to receive the configuration
> >> you
> >>>>>> could use multi-location support and set the location to "?" With
> the
> >>>> code
> >>>>>> you have now, if the configuration is already in use by a DS
> >> component,
> >>>> the
> >>>>>> location changed event will result in the bundle location being
> reset
> >>>> back
> >>>>>> to what it was.
> >>>>>>>>>
> >>>>>>>>> thanks!
> >>>>>>>>> david jencks
> >>>>>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <
> pierre.derop@gmail.com
> >>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi David,
> >>>>>>>>>>
> >>>>>>>>>> thanks; The fix is fixing the problem :-)
> >>>>>>>>>>
> >>>>>>>>>> but ... there's now a new different problem: i'm now sometimes
> >>>>>> getting this
> >>>>>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >>>>>>>>>>
> >>>>>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
> >>>> ConfigurationEvent:
> >>>>>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>>>>>>>> configuration event to
> [org.osgi.service.cm.ConfigurationListener,
> >>>>>> id=102,
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>>>>>>
> >>>>>>>>>> java.lang.NullPointerException
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>>>>>>> at
> >>>>>>>>>>
> >>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>>>>>>> at
> >>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>>>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>>>>>
> >>>>>>>>>> Perhaps a new jira issue shall be opened ?
> >>>>>>>>>>
> >>>>>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in
> our
> >>>>>>>>>> application, we populate configuration admin by doing something
> >> like
> >>>>>> this:
> >>>>>>>>>>
> >>>>>>>>>> Configuration cfg = cm.getConfiguration(pid, null)
> >>>>>>>>>> if (config.getBundleLocation() != null) {
> >>>>>>>>>> config.setBundleLocation(null);
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> The setBundleLocation(null) is probably useless, but this leads
> >> to a
> >>>>>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
> >>>> NPE.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Friday, October 25, 2013, David Jencks <
> david_jencks@yahoo.com
> >>>
> >>>>>> wrote:
> >>>>>>>>>>> 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
> >>>>>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Hi Pierre,
I think I see what's going on and I wrote a test case for my theory and fixed it. Can you try again?
many thanks!
david jencks
On Oct 29, 2013, at 4:00 PM, Pierre De Rop <pi...@gmail.com> wrote:
> Hi David,
>
> no, I did not notice the ERROR message you are mentioning.
> (see the full logs in stacktrace2.log which I juste attached in the issue).
>
> Please forget my comment about the thread dump in WARN. I did not realize
> that it was intentional to log it in DEBUG.
>
> regards;
> /Pierre
>
>
> On Tue, Oct 29, 2013 at 6:40 PM, David Jencks <da...@yahoo.com>wrote:
>
>> HI Pierre,
>>
>> Do you by any chance see a log message at ERROR level like
>>
>> Cannot create component instance due to failure to bind reference {0}
>>
>> shortly before the timeout message?
>>
>> I'm not sure if it's a good idea to dump the threads at WARN. If you
>> think it is I'll change it. Some people get upset if the logs are too long
>> :-)
>>
>> thanks
>> david jencks
>>
>>
>> On Oct 29, 2013, at 8:46 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>
>>> yes David, consistently. but I don't see stacktraces.
>>>
>>> Now, looking at the code, I see that this stacktrace is logged in DEBUG:
>>>
>>> final void dumpThreads()
>>> {
>>> try
>>> {
>>> String dump = new ThreadDump().call();
>>> log( LogService.LOG_DEBUG, dump, null );
>>>
>>> So, I will activate DEBUG and provide the stacktrace.
>>>
>>> But is this a bug to log this stacktrace in DEBUG ?
>>> I mean: should it be logged in WARN, instead of DEBUG ?
>>>
>>> /pierre
>>>
>>>
>>> On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <david_jencks@yahoo.com
>>> wrote:
>>>
>>>> Hi Pierre,
>>>>
>>>> I think there should be a thread dump in the log to go with this
>> message.
>>>> If there is could you send it to me or attach it to FELIX-4297?
>>>>
>>>> Does this happen consistently?
>>>>
>>>> many thanks
>>>> david jencks
>>>>
>>>> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com>
>> wrote:
>>>>
>>>>> Hi David;
>>>>>
>>>>> 1) Every integration tests are passing OK.
>>>>>
>>>>> Regarding the OOM, I believe that the out of memory is likely to be
>> cause
>>>>> by the following load tests, which are running in DEBUG mode:
>>>>>
>>>>>
>>>>
>> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
>>>>> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
>>>>> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
>>>>>
>>>>>
>>>>> So, I just added this in each files (in static initializers):
>>>>>
>>>>> DS_LOGLEVEL = "warn";
>>>>>
>>>>> And I have no more OOM, with this nice test result message:
>>>>>
>>>>> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
>>>>> [INFO] BUILD SUCCESS
>>>>>
>>>>>
>>>>>
>>>>> 2) Now, I did again a non regression tests with our applications, and
>> I'm
>>>>> seeing a new WARN message (but it does not seem to prevent the
>>>> application
>>>>> to be correctly initialized: all components are in the end satisfied):
>>>>>
>>>>> (if you believe that it's now time to release, then you can go ahead,
>> and
>>>>> we'll then investigate this new issue after the release ... I let you
>>>>> decide)
>>>>>
>>>>> ->
>>>>>
>>>>> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
>>>>> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
>>>>> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)]
>> DependencyManager
>>>> :
>>>>> invokeBindMethod : timeout on open latch newtcpprocessor
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> kind regards;
>>>>> /Pierre
>>>>>
>>>>>
>>>>> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <david_jencks@yahoo.com
>>>>> wrote:
>>>>>
>>>>>> Pierre,
>>>>>>
>>>>>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed
>> the
>>>>>> problems I found (for 2). I don't see the OOM often enough to have
>> any
>>>>>> confidence that anything I do would actually fix it, so I'm inclined
>> to
>>>> do
>>>>>> nothing. Is that OK with you?
>>>>>>
>>>>>> Unless you can find some more problems :-) I'm planning to try
>> another
>>>>>> release when the config admin 1.8 gets to maven central. I'm going to
>>>>>> update the pom to normally run against the CA 1.8 version supporting
>> R5
>>>> and
>>>>>> change the profile so running against R4 requires specifying profiles
>>>>>> explicitly.
>>>>>>
>>>>>> thanks again!
>>>>>> david jencks
>>>>>>
>>>>>> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>>
>>>>>>> Hi Pierre,
>>>>>>>
>>>>>>> Much better to find these problems before a release than just after!
>>>>>>>
>>>>>>> I saw an OOM once recently but haven't been able to reproduce it.
>>>>>>>
>>>>>>> I'm looking into the NPE. I think I see the timing hole it is using
>>>> but
>>>>>> need to think about it some more.
>>>>>>>
>>>>>>> many thanks!
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Looking at our configurator component we are currently using (but we
>>>>>> will fix it in order to use the multi-location "?"), I see this:
>>>>>>>>
>>>>>>>> void configure(String pid, Dictionary pidConf) {
>>>>>>>> Configuration config = getConfiguration(_pid, null);
>>>>>>>> if (config.getBundleLocation() != null) {
>>>>>>>> config.setBundleLocation(null);
>>>>>>>> }
>>>>>>>> config.update(pidConf);
>>>>>>>> }
>>>>>>>>
>>>>>>>> So I believe that you are getting a null configuration because there
>>>> is
>>>>>> a short window between the setBundleLocation(null) (at this point, the
>>>>>> configuration is null) and the config.update(pidConf) call ...
>>>>>>>>
>>>>>>>> So, the good news is that I'm not having anymore some NPE using your
>>>>>> latest commits :-) and I think our application is now fully
>> operational.
>>>>>>>>
>>>>>>>> but ... (please don't start to abominate me ) now, in order to do a
>>>>>> final check, I restarted the integration tests and there is still two
>>>>>> problems:
>>>>>>>>
>>>>>>>> 1) I'm sometimes getting some out of memory errors: this is probably
>>>>>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
>>>>>> currently configured in DEBUG mode ?
>>>>>>>>
>>>>>>>> 2) I ran the tests two times, and the second time, I got this
>>>> exception
>>>>>> with the failing
>>>>>>>> Felix3680_2Test:
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
>>>>>> Time elapsed: 36.597 sec <<< ERROR!
>>>>>>>> java.lang.NullPointerException
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>>>>>>>> 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:4260)
>>>>>>>> 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:148)
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>>>>>>>> at
>>>>>>
>>>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>>>> at
>>>>>>
>>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>>>
>>>>>>>> Are you also getting this exception ?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>>
>>>>>>>> /Pierre
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <
>> david_jencks@yahoo.com
>>>>>
>>>>>> wrote:
>>>>>>>> Hi PIerre,
>>>>>>>>
>>>>>>>> Looking at the CA spec it looks like CA is supposed to send out
>>>>>> CM_LOCATION_CHANGED events even before any properties are set when
>>>>>> setBundleLocation is called. I added some code to ignore these
>> events.
>>>>>> Note that DS is "reserving" the configurations for (one of) the
>>>>>> component(s) that will be consuming them by calling
>>>> getConfiguration(pid).
>>>>>>>>
>>>>>>>> I do wonder how the location to something non-null on your
>>>>>> configurations before the properties are set.
>>>>>>>>
>>>>>>>> Waiting for the next bug :-)
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hello David,
>>>>>>>>>
>>>>>>>>> The code we are using to configure our components is old, at at the
>>>>>> time we wrote it, configadmin was not supporting multi-location. But I
>>>> do
>>>>>> agree, we can now use the "?" multi-location.
>>>>>>>>>
>>>>>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
>>>>>> always):
>>>>>>>>>
>>>>>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire
>> ConfigurationEvent:
>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>>>> id=102,
>>>>>>
>>>>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>>>>>
>>>>>>>>> java.lang.NullPointerException
>>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>>>>>> at
>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>>>>>> at
>>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
>>>>>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct,
>>>> then
>>>>>> Is this a normal behavior ?
>>>>>>>>>
>>>>>>>>> This is strange; perhaps I shall start a new integration test ?
>>>>>>>>>
>>>>>>>>> /Pierre
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
>>>> david_jencks@yahoo.com>
>>>>>> wrote:
>>>>>>>>> Hi Pierre,
>>>>>>>>>
>>>>>>>>> This pointed out a logic error I introduced for Felix 3651. I
>> opened
>>>>>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error
>> I
>>>>>> found which I think explains the NPE. Could you check this?
>>>>>>>>>
>>>>>>>>> Could I ask what you are trying to do by setting the bundleLocation
>>>> to
>>>>>> null? If you want to allow any bundle to receive the configuration
>> you
>>>>>> could use multi-location support and set the location to "?" With the
>>>> code
>>>>>> you have now, if the configuration is already in use by a DS
>> component,
>>>> the
>>>>>> location changed event will result in the bundle location being reset
>>>> back
>>>>>> to what it was.
>>>>>>>>>
>>>>>>>>> thanks!
>>>>>>>>> david jencks
>>>>>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pierre.derop@gmail.com
>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> thanks; The fix is fixing the problem :-)
>>>>>>>>>>
>>>>>>>>>> but ... there's now a new different problem: i'm now sometimes
>>>>>> getting this
>>>>>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>>>>>>>>>>
>>>>>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
>>>> ConfigurationEvent:
>>>>>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>>>>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>>>>>> id=102,
>>>>>>>>>>
>>>>>>
>>>>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>>>>>>
>>>>>>>>>> java.lang.NullPointerException
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>
>>>>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>>>>>>> at
>>>>>>>>>>
>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>>>>>>> at
>>>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>>>>>
>>>>>>>>>> Perhaps a new jira issue shall be opened ?
>>>>>>>>>>
>>>>>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>>>>>>>>>> application, we populate configuration admin by doing something
>> like
>>>>>> this:
>>>>>>>>>>
>>>>>>>>>> Configuration cfg = cm.getConfiguration(pid, null)
>>>>>>>>>> if (config.getBundleLocation() != null) {
>>>>>>>>>> config.setBundleLocation(null);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The setBundleLocation(null) is probably useless, but this leads
>> to a
>>>>>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
>>>> NPE.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Friday, October 25, 2013, David Jencks <david_jencks@yahoo.com
>>>
>>>>>> wrote:
>>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David,
no, I did not notice the ERROR message you are mentioning.
(see the full logs in stacktrace2.log which I juste attached in the issue).
Please forget my comment about the thread dump in WARN. I did not realize
that it was intentional to log it in DEBUG.
regards;
/Pierre
On Tue, Oct 29, 2013 at 6:40 PM, David Jencks <da...@yahoo.com>wrote:
> HI Pierre,
>
> Do you by any chance see a log message at ERROR level like
>
> Cannot create component instance due to failure to bind reference {0}
>
> shortly before the timeout message?
>
> I'm not sure if it's a good idea to dump the threads at WARN. If you
> think it is I'll change it. Some people get upset if the logs are too long
> :-)
>
> thanks
> david jencks
>
>
> On Oct 29, 2013, at 8:46 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > yes David, consistently. but I don't see stacktraces.
> >
> > Now, looking at the code, I see that this stacktrace is logged in DEBUG:
> >
> > final void dumpThreads()
> > {
> > try
> > {
> > String dump = new ThreadDump().call();
> > log( LogService.LOG_DEBUG, dump, null );
> >
> > So, I will activate DEBUG and provide the stacktrace.
> >
> > But is this a bug to log this stacktrace in DEBUG ?
> > I mean: should it be logged in WARN, instead of DEBUG ?
> >
> > /pierre
> >
> >
> > On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <david_jencks@yahoo.com
> >wrote:
> >
> >> Hi Pierre,
> >>
> >> I think there should be a thread dump in the log to go with this
> message.
> >> If there is could you send it to me or attach it to FELIX-4297?
> >>
> >> Does this happen consistently?
> >>
> >> many thanks
> >> david jencks
> >>
> >> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >>
> >>> Hi David;
> >>>
> >>> 1) Every integration tests are passing OK.
> >>>
> >>> Regarding the OOM, I believe that the out of memory is likely to be
> cause
> >>> by the following load tests, which are running in DEBUG mode:
> >>>
> >>>
> >>
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> >>> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
> >>> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
> >>>
> >>>
> >>> So, I just added this in each files (in static initializers):
> >>>
> >>> DS_LOGLEVEL = "warn";
> >>>
> >>> And I have no more OOM, with this nice test result message:
> >>>
> >>> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
> >>> [INFO] BUILD SUCCESS
> >>>
> >>>
> >>>
> >>> 2) Now, I did again a non regression tests with our applications, and
> I'm
> >>> seeing a new WARN message (but it does not seem to prevent the
> >> application
> >>> to be correctly initialized: all components are in the end satisfied):
> >>>
> >>> (if you believe that it's now time to release, then you can go ahead,
> and
> >>> we'll then investigate this new issue after the release ... I let you
> >>> decide)
> >>>
> >>> ->
> >>>
> >>> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
> >>> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
> >>> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)]
> DependencyManager
> >> :
> >>> invokeBindMethod : timeout on open latch newtcpprocessor
> >>>
> >>>
> >>>
> >>>
> >>> kind regards;
> >>> /Pierre
> >>>
> >>>
> >>> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <david_jencks@yahoo.com
> >>> wrote:
> >>>
> >>>> Pierre,
> >>>>
> >>>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed
> the
> >>>> problems I found (for 2). I don't see the OOM often enough to have
> any
> >>>> confidence that anything I do would actually fix it, so I'm inclined
> to
> >> do
> >>>> nothing. Is that OK with you?
> >>>>
> >>>> Unless you can find some more problems :-) I'm planning to try
> another
> >>>> release when the config admin 1.8 gets to maven central. I'm going to
> >>>> update the pom to normally run against the CA 1.8 version supporting
> R5
> >> and
> >>>> change the profile so running against R4 requires specifying profiles
> >>>> explicitly.
> >>>>
> >>>> thanks again!
> >>>> david jencks
> >>>>
> >>>> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
> >> wrote:
> >>>>
> >>>>> Hi Pierre,
> >>>>>
> >>>>> Much better to find these problems before a release than just after!
> >>>>>
> >>>>> I saw an OOM once recently but haven't been able to reproduce it.
> >>>>>
> >>>>> I'm looking into the NPE. I think I see the timing hole it is using
> >> but
> >>>> need to think about it some more.
> >>>>>
> >>>>> many thanks!
> >>>>> david jencks
> >>>>>
> >>>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>> Hi David,
> >>>>>>
> >>>>>> Looking at our configurator component we are currently using (but we
> >>>> will fix it in order to use the multi-location "?"), I see this:
> >>>>>>
> >>>>>> void configure(String pid, Dictionary pidConf) {
> >>>>>> Configuration config = getConfiguration(_pid, null);
> >>>>>> if (config.getBundleLocation() != null) {
> >>>>>> config.setBundleLocation(null);
> >>>>>> }
> >>>>>> config.update(pidConf);
> >>>>>> }
> >>>>>>
> >>>>>> So I believe that you are getting a null configuration because there
> >> is
> >>>> a short window between the setBundleLocation(null) (at this point, the
> >>>> configuration is null) and the config.update(pidConf) call ...
> >>>>>>
> >>>>>> So, the good news is that I'm not having anymore some NPE using your
> >>>> latest commits :-) and I think our application is now fully
> operational.
> >>>>>>
> >>>>>> but ... (please don't start to abominate me ) now, in order to do a
> >>>> final check, I restarted the integration tests and there is still two
> >>>> problems:
> >>>>>>
> >>>>>> 1) I'm sometimes getting some out of memory errors: this is probably
> >>>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
> >>>> currently configured in DEBUG mode ?
> >>>>>>
> >>>>>> 2) I ran the tests two times, and the second time, I got this
> >> exception
> >>>> with the failing
> >>>>>> Felix3680_2Test:
> >>>>>>
> >>>>>>
> >>>>
> >>
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
> >>>> Time elapsed: 36.597 sec <<< ERROR!
> >>>>>> java.lang.NullPointerException
> >>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> >>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> >>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> >>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> >>>>>> 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:4260)
> >>>>>> 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:148)
> >>>>>> at
> >>>>
> >>
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> >>>>>> at
> >>>>
> >>
> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> >>>>>> at
> >>>>
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>>>> at
> >>>>
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>
> >>>>>> Are you also getting this exception ?
> >>>>>>
> >>>>>> thanks
> >>>>>>
> >>>>>> /Pierre
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <
> david_jencks@yahoo.com
> >>>
> >>>> wrote:
> >>>>>> Hi PIerre,
> >>>>>>
> >>>>>> Looking at the CA spec it looks like CA is supposed to send out
> >>>> CM_LOCATION_CHANGED events even before any properties are set when
> >>>> setBundleLocation is called. I added some code to ignore these
> events.
> >>>> Note that DS is "reserving" the configurations for (one of) the
> >>>> component(s) that will be consuming them by calling
> >> getConfiguration(pid).
> >>>>>>
> >>>>>> I do wonder how the location to something non-null on your
> >>>> configurations before the properties are set.
> >>>>>>
> >>>>>> Waiting for the next bug :-)
> >>>>>>
> >>>>>> thanks
> >>>>>> david jencks
> >>>>>>
> >>>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Hello David,
> >>>>>>>
> >>>>>>> The code we are using to configure our components is old, at at the
> >>>> time we wrote it, configadmin was not supporting multi-location. But I
> >> do
> >>>> agree, we can now use the "?" multi-location.
> >>>>>>>
> >>>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
> >>>> always):
> >>>>>>>
> >>>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire
> ConfigurationEvent:
> >>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
> >> id=102,
> >>>>
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>>>
> >>>>>>> java.lang.NullPointerException
> >>>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>>>> at
> >>>>
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> >>>>>>> at
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>>>> at
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>>>> at
> >>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>>
> >>>>>>>
> >>>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
> >>>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct,
> >> then
> >>>> Is this a normal behavior ?
> >>>>>>>
> >>>>>>> This is strange; perhaps I shall start a new integration test ?
> >>>>>>>
> >>>>>>> /Pierre
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
> >> david_jencks@yahoo.com>
> >>>> wrote:
> >>>>>>> Hi Pierre,
> >>>>>>>
> >>>>>>> This pointed out a logic error I introduced for Felix 3651. I
> opened
> >>>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error
> I
> >>>> found which I think explains the NPE. Could you check this?
> >>>>>>>
> >>>>>>> Could I ask what you are trying to do by setting the bundleLocation
> >> to
> >>>> null? If you want to allow any bundle to receive the configuration
> you
> >>>> could use multi-location support and set the location to "?" With the
> >> code
> >>>> you have now, if the configuration is already in use by a DS
> component,
> >> the
> >>>> location changed event will result in the bundle location being reset
> >> back
> >>>> to what it was.
> >>>>>>>
> >>>>>>> thanks!
> >>>>>>> david jencks
> >>>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pierre.derop@gmail.com
> >
> >>>> wrote:
> >>>>>>>
> >>>>>>>> Hi David,
> >>>>>>>>
> >>>>>>>> thanks; The fix is fixing the problem :-)
> >>>>>>>>
> >>>>>>>> but ... there's now a new different problem: i'm now sometimes
> >>>> getting this
> >>>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >>>>>>>>
> >>>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
> >> ConfigurationEvent:
> >>>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
> >>>> id=102,
> >>>>>>>>
> >>>>
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>>>>
> >>>>>>>> java.lang.NullPointerException
> >>>>>>>> at
> >>>>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>>>>> at
> >>>>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>>>>> at
> >>>>>>>>
> >>>>
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> >>>>>>>> at
> >>>>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>>>>> at
> >>>>>>>>
> >>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>>>>> at
> >>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>>>
> >>>>>>>> Perhaps a new jira issue shall be opened ?
> >>>>>>>>
> >>>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
> >>>>>>>> application, we populate configuration admin by doing something
> like
> >>>> this:
> >>>>>>>>
> >>>>>>>> Configuration cfg = cm.getConfiguration(pid, null)
> >>>>>>>> if (config.getBundleLocation() != null) {
> >>>>>>>> config.setBundleLocation(null);
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> The setBundleLocation(null) is probably useless, but this leads
> to a
> >>>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
> >> NPE.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Friday, October 25, 2013, David Jencks <david_jencks@yahoo.com
> >
> >>>> wrote:
> >>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
HI Pierre,
Do you by any chance see a log message at ERROR level like
Cannot create component instance due to failure to bind reference {0}
shortly before the timeout message?
I'm not sure if it's a good idea to dump the threads at WARN. If you think it is I'll change it. Some people get upset if the logs are too long :-)
thanks
david jencks
On Oct 29, 2013, at 8:46 AM, Pierre De Rop <pi...@gmail.com> wrote:
> yes David, consistently. but I don't see stacktraces.
>
> Now, looking at the code, I see that this stacktrace is logged in DEBUG:
>
> final void dumpThreads()
> {
> try
> {
> String dump = new ThreadDump().call();
> log( LogService.LOG_DEBUG, dump, null );
>
> So, I will activate DEBUG and provide the stacktrace.
>
> But is this a bug to log this stacktrace in DEBUG ?
> I mean: should it be logged in WARN, instead of DEBUG ?
>
> /pierre
>
>
> On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <da...@yahoo.com>wrote:
>
>> Hi Pierre,
>>
>> I think there should be a thread dump in the log to go with this message.
>> If there is could you send it to me or attach it to FELIX-4297?
>>
>> Does this happen consistently?
>>
>> many thanks
>> david jencks
>>
>> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>
>>> Hi David;
>>>
>>> 1) Every integration tests are passing OK.
>>>
>>> Regarding the OOM, I believe that the out of memory is likely to be cause
>>> by the following load tests, which are running in DEBUG mode:
>>>
>>>
>> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
>>> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
>>> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
>>>
>>>
>>> So, I just added this in each files (in static initializers):
>>>
>>> DS_LOGLEVEL = "warn";
>>>
>>> And I have no more OOM, with this nice test result message:
>>>
>>> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
>>> [INFO] BUILD SUCCESS
>>>
>>>
>>>
>>> 2) Now, I did again a non regression tests with our applications, and I'm
>>> seeing a new WARN message (but it does not seem to prevent the
>> application
>>> to be correctly initialized: all components are in the end satisfied):
>>>
>>> (if you believe that it's now time to release, then you can go ahead, and
>>> we'll then investigate this new issue after the release ... I let you
>>> decide)
>>>
>>> ->
>>>
>>> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
>>> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
>>> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)] DependencyManager
>> :
>>> invokeBindMethod : timeout on open latch newtcpprocessor
>>>
>>>
>>>
>>>
>>> kind regards;
>>> /Pierre
>>>
>>>
>>> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <david_jencks@yahoo.com
>>> wrote:
>>>
>>>> Pierre,
>>>>
>>>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the
>>>> problems I found (for 2). I don't see the OOM often enough to have any
>>>> confidence that anything I do would actually fix it, so I'm inclined to
>> do
>>>> nothing. Is that OK with you?
>>>>
>>>> Unless you can find some more problems :-) I'm planning to try another
>>>> release when the config admin 1.8 gets to maven central. I'm going to
>>>> update the pom to normally run against the CA 1.8 version supporting R5
>> and
>>>> change the profile so running against R4 requires specifying profiles
>>>> explicitly.
>>>>
>>>> thanks again!
>>>> david jencks
>>>>
>>>> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>>>
>>>>> Hi Pierre,
>>>>>
>>>>> Much better to find these problems before a release than just after!
>>>>>
>>>>> I saw an OOM once recently but haven't been able to reproduce it.
>>>>>
>>>>> I'm looking into the NPE. I think I see the timing hole it is using
>> but
>>>> need to think about it some more.
>>>>>
>>>>> many thanks!
>>>>> david jencks
>>>>>
>>>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> Looking at our configurator component we are currently using (but we
>>>> will fix it in order to use the multi-location "?"), I see this:
>>>>>>
>>>>>> void configure(String pid, Dictionary pidConf) {
>>>>>> Configuration config = getConfiguration(_pid, null);
>>>>>> if (config.getBundleLocation() != null) {
>>>>>> config.setBundleLocation(null);
>>>>>> }
>>>>>> config.update(pidConf);
>>>>>> }
>>>>>>
>>>>>> So I believe that you are getting a null configuration because there
>> is
>>>> a short window between the setBundleLocation(null) (at this point, the
>>>> configuration is null) and the config.update(pidConf) call ...
>>>>>>
>>>>>> So, the good news is that I'm not having anymore some NPE using your
>>>> latest commits :-) and I think our application is now fully operational.
>>>>>>
>>>>>> but ... (please don't start to abominate me ) now, in order to do a
>>>> final check, I restarted the integration tests and there is still two
>>>> problems:
>>>>>>
>>>>>> 1) I'm sometimes getting some out of memory errors: this is probably
>>>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
>>>> currently configured in DEBUG mode ?
>>>>>>
>>>>>> 2) I ran the tests two times, and the second time, I got this
>> exception
>>>> with the failing
>>>>>> Felix3680_2Test:
>>>>>>
>>>>>>
>>>>
>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
>>>> Time elapsed: 36.597 sec <<< ERROR!
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>>>>>> 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:4260)
>>>>>> 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:148)
>>>>>> at
>>>>
>> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>>>>>> at
>>>>
>> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>>>>>> at
>>>>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>>>> at
>>>>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>
>>>>>> Are you also getting this exception ?
>>>>>>
>>>>>> thanks
>>>>>>
>>>>>> /Pierre
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <david_jencks@yahoo.com
>>>
>>>> wrote:
>>>>>> Hi PIerre,
>>>>>>
>>>>>> Looking at the CA spec it looks like CA is supposed to send out
>>>> CM_LOCATION_CHANGED events even before any properties are set when
>>>> setBundleLocation is called. I added some code to ignore these events.
>>>> Note that DS is "reserving" the configurations for (one of) the
>>>> component(s) that will be consuming them by calling
>> getConfiguration(pid).
>>>>>>
>>>>>> I do wonder how the location to something non-null on your
>>>> configurations before the properties are set.
>>>>>>
>>>>>> Waiting for the next bug :-)
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
>>>> wrote:
>>>>>>
>>>>>>> Hello David,
>>>>>>>
>>>>>>> The code we are using to configure our components is old, at at the
>>>> time we wrote it, configadmin was not supporting multi-location. But I
>> do
>>>> agree, we can now use the "?" multi-location.
>>>>>>>
>>>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
>>>> always):
>>>>>>>
>>>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>> id=102,
>>>>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>>>
>>>>>>> java.lang.NullPointerException
>>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>>>> at
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>>>> at
>>>>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>>>>>>> at
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>>>> at
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>>>> at
>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>>
>>>>>>>
>>>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
>>>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct,
>> then
>>>> Is this a normal behavior ?
>>>>>>>
>>>>>>> This is strange; perhaps I shall start a new integration test ?
>>>>>>>
>>>>>>> /Pierre
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
>> david_jencks@yahoo.com>
>>>> wrote:
>>>>>>> Hi Pierre,
>>>>>>>
>>>>>>> This pointed out a logic error I introduced for Felix 3651. I opened
>>>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
>>>> found which I think explains the NPE. Could you check this?
>>>>>>>
>>>>>>> Could I ask what you are trying to do by setting the bundleLocation
>> to
>>>> null? If you want to allow any bundle to receive the configuration you
>>>> could use multi-location support and set the location to "?" With the
>> code
>>>> you have now, if the configuration is already in use by a DS component,
>> the
>>>> location changed event will result in the bundle location being reset
>> back
>>>> to what it was.
>>>>>>>
>>>>>>> thanks!
>>>>>>> david jencks
>>>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> thanks; The fix is fixing the problem :-)
>>>>>>>>
>>>>>>>> but ... there's now a new different problem: i'm now sometimes
>>>> getting this
>>>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>>>>>>>>
>>>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
>> ConfigurationEvent:
>>>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>>>> id=102,
>>>>>>>>
>>>>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>>>>
>>>>>>>> java.lang.NullPointerException
>>>>>>>> at
>>>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>>>>> at
>>>>>>>>
>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>>>>> at
>>>>>>>>
>>>>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>>>>>>>> at
>>>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>>>>> at
>>>>>>>>
>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>>>>> at
>>>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>>>
>>>>>>>> Perhaps a new jira issue shall be opened ?
>>>>>>>>
>>>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>>>>>>>> application, we populate configuration admin by doing something like
>>>> this:
>>>>>>>>
>>>>>>>> Configuration cfg = cm.getConfiguration(pid, null)
>>>>>>>> if (config.getBundleLocation() != null) {
>>>>>>>> config.setBundleLocation(null);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The setBundleLocation(null) is probably useless, but this leads to a
>>>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
>> NPE.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
David, I just attached the stacktrace to the FELIX-4297
On Tue, Oct 29, 2013 at 4:46 PM, Pierre De Rop <pi...@gmail.com>wrote:
> yes David, consistently. but I don't see stacktraces.
>
> Now, looking at the code, I see that this stacktrace is logged in DEBUG:
>
> final void dumpThreads()
> {
> try
> {
> String dump = new ThreadDump().call();
> log( LogService.LOG_DEBUG, dump, null );
>
> So, I will activate DEBUG and provide the stacktrace.
>
> But is this a bug to log this stacktrace in DEBUG ?
> I mean: should it be logged in WARN, instead of DEBUG ?
>
> /pierre
>
>
> On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <da...@yahoo.com>wrote:
>
>> Hi Pierre,
>>
>> I think there should be a thread dump in the log to go with this message.
>> If there is could you send it to me or attach it to FELIX-4297?
>>
>> Does this happen consistently?
>>
>> many thanks
>> david jencks
>>
>> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com>
>> wrote:
>>
>> > Hi David;
>> >
>> > 1) Every integration tests are passing OK.
>> >
>> > Regarding the OOM, I believe that the out of memory is likely to be
>> cause
>> > by the following load tests, which are running in DEBUG mode:
>> >
>> >
>> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
>> > src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
>> > src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
>> >
>> >
>> > So, I just added this in each files (in static initializers):
>> >
>> > DS_LOGLEVEL = "warn";
>> >
>> > And I have no more OOM, with this nice test result message:
>> >
>> > Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
>> > [INFO] BUILD SUCCESS
>> >
>> >
>> >
>> > 2) Now, I did again a non regression tests with our applications, and
>> I'm
>> > seeing a new WARN message (but it does not seem to prevent the
>> application
>> > to be correctly initialized: all components are in the end satisfied):
>> >
>> > (if you believe that it's now time to release, then you can go ahead,
>> and
>> > we'll then investigate this new issue after the release ... I let you
>> > decide)
>> >
>> > ->
>> >
>> > 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
>> > pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
>> > [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)]
>> DependencyManager :
>> > invokeBindMethod : timeout on open latch newtcpprocessor
>> >
>> >
>> >
>> >
>> > kind regards;
>> > /Pierre
>> >
>> >
>> > On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <david_jencks@yahoo.com
>> >wrote:
>> >
>> >> Pierre,
>> >>
>> >> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed
>> the
>> >> problems I found (for 2). I don't see the OOM often enough to have any
>> >> confidence that anything I do would actually fix it, so I'm inclined
>> to do
>> >> nothing. Is that OK with you?
>> >>
>> >> Unless you can find some more problems :-) I'm planning to try another
>> >> release when the config admin 1.8 gets to maven central. I'm going to
>> >> update the pom to normally run against the CA 1.8 version supporting
>> R5 and
>> >> change the profile so running against R4 requires specifying profiles
>> >> explicitly.
>> >>
>> >> thanks again!
>> >> david jencks
>> >>
>> >> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
>> wrote:
>> >>
>> >>> Hi Pierre,
>> >>>
>> >>> Much better to find these problems before a release than just after!
>> >>>
>> >>> I saw an OOM once recently but haven't been able to reproduce it.
>> >>>
>> >>> I'm looking into the NPE. I think I see the timing hole it is using
>> but
>> >> need to think about it some more.
>> >>>
>> >>> many thanks!
>> >>> david jencks
>> >>>
>> >>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
>> >> wrote:
>> >>>
>> >>>> Hi David,
>> >>>>
>> >>>> Looking at our configurator component we are currently using (but we
>> >> will fix it in order to use the multi-location "?"), I see this:
>> >>>>
>> >>>> void configure(String pid, Dictionary pidConf) {
>> >>>> Configuration config = getConfiguration(_pid, null);
>> >>>> if (config.getBundleLocation() != null) {
>> >>>> config.setBundleLocation(null);
>> >>>> }
>> >>>> config.update(pidConf);
>> >>>> }
>> >>>>
>> >>>> So I believe that you are getting a null configuration because there
>> is
>> >> a short window between the setBundleLocation(null) (at this point, the
>> >> configuration is null) and the config.update(pidConf) call ...
>> >>>>
>> >>>> So, the good news is that I'm not having anymore some NPE using your
>> >> latest commits :-) and I think our application is now fully
>> operational.
>> >>>>
>> >>>> but ... (please don't start to abominate me ) now, in order to do a
>> >> final check, I restarted the integration tests and there is still two
>> >> problems:
>> >>>>
>> >>>> 1) I'm sometimes getting some out of memory errors: this is probably
>> >> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
>> >> currently configured in DEBUG mode ?
>> >>>>
>> >>>> 2) I ran the tests two times, and the second time, I got this
>> exception
>> >> with the failing
>> >>>> Felix3680_2Test:
>> >>>>
>> >>>>
>> >>
>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
>> >> Time elapsed: 36.597 sec <<< ERROR!
>> >>>> java.lang.NullPointerException
>> >>>> at
>> >>
>> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>> >>>> at
>> >>
>> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>> >>>> at
>> >>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>> >>>> at
>> >>
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>> >>>> 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:4260)
>> >>>> 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:148)
>> >>>> at
>> >>
>> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>> >>>> at
>> >>
>> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>> >>>> at
>> >>
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> >>>> at
>> >>
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> >>>> at java.lang.Thread.run(Thread.java:722)
>> >>>>
>> >>>> Are you also getting this exception ?
>> >>>>
>> >>>> thanks
>> >>>>
>> >>>> /Pierre
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <
>> david_jencks@yahoo.com>
>> >> wrote:
>> >>>> Hi PIerre,
>> >>>>
>> >>>> Looking at the CA spec it looks like CA is supposed to send out
>> >> CM_LOCATION_CHANGED events even before any properties are set when
>> >> setBundleLocation is called. I added some code to ignore these events.
>> >> Note that DS is "reserving" the configurations for (one of) the
>> >> component(s) that will be consuming them by calling
>> getConfiguration(pid).
>> >>>>
>> >>>> I do wonder how the location to something non-null on your
>> >> configurations before the properties are set.
>> >>>>
>> >>>> Waiting for the next bug :-)
>> >>>>
>> >>>> thanks
>> >>>> david jencks
>> >>>>
>> >>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
>> >> wrote:
>> >>>>
>> >>>>> Hello David,
>> >>>>>
>> >>>>> The code we are using to configure our components is old, at at the
>> >> time we wrote it, configadmin was not supporting multi-location. But I
>> do
>> >> agree, we can now use the "?" multi-location.
>> >>>>>
>> >>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
>> >> always):
>> >>>>>
>> >>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire
>> ConfigurationEvent:
>> >> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>> >> configuration event to [org.osgi.service.cm.ConfigurationListener,
>> id=102,
>> >>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>> >>>>>
>> >>>>> java.lang.NullPointerException
>> >>>>> at
>> >>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>> >>>>> at
>> >>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>> >>>>> at
>> >>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>> >>>>> at
>> >>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>> >>>>> at
>> >>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>> >>>>> at
>> >> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>> >>>>> at java.lang.Thread.run(Thread.java:722)
>> >>>>>
>> >>>>>
>> >>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
>> >> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct,
>> then
>> >> Is this a normal behavior ?
>> >>>>>
>> >>>>> This is strange; perhaps I shall start a new integration test ?
>> >>>>>
>> >>>>> /Pierre
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
>> david_jencks@yahoo.com>
>> >> wrote:
>> >>>>> Hi Pierre,
>> >>>>>
>> >>>>> This pointed out a logic error I introduced for Felix 3651. I
>> opened
>> >> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
>> >> found which I think explains the NPE. Could you check this?
>> >>>>>
>> >>>>> Could I ask what you are trying to do by setting the bundleLocation
>> to
>> >> null? If you want to allow any bundle to receive the configuration you
>> >> could use multi-location support and set the location to "?" With the
>> code
>> >> you have now, if the configuration is already in use by a DS
>> component, the
>> >> location changed event will result in the bundle location being reset
>> back
>> >> to what it was.
>> >>>>>
>> >>>>> thanks!
>> >>>>> david jencks
>> >>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
>> >> wrote:
>> >>>>>
>> >>>>>> Hi David,
>> >>>>>>
>> >>>>>> thanks; The fix is fixing the problem :-)
>> >>>>>>
>> >>>>>> but ... there's now a new different problem: i'm now sometimes
>> >> getting this
>> >>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>> >>>>>>
>> >>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
>> ConfigurationEvent:
>> >>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>> >>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>> >> id=102,
>> >>>>>>
>> >>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>> >>>>>>
>> >>>>>> java.lang.NullPointerException
>> >>>>>> at
>> >>>>>>
>> >>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>> >>>>>> at
>> >>>>>>
>> >>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>> >>>>>> at
>> >>>>>>
>> >>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>> >>>>>> at
>> >>>>>>
>> >>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>> >>>>>> at
>> >>>>>>
>> >>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>> >>>>>> at
>> >> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>> >>>>>> at java.lang.Thread.run(Thread.java:722)
>> >>>>>>
>> >>>>>> Perhaps a new jira issue shall be opened ?
>> >>>>>>
>> >>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>> >>>>>> application, we populate configuration admin by doing something
>> like
>> >> this:
>> >>>>>>
>> >>>>>> Configuration cfg = cm.getConfiguration(pid, null)
>> >>>>>> if (config.getBundleLocation() != null) {
>> >>>>>> config.setBundleLocation(null);
>> >>>>>> }
>> >>>>>>
>> >>>>>> The setBundleLocation(null) is probably useless, but this leads to
>> a
>> >>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
>> NPE.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
>> >> wrote:
>> >>>>>>> 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
>> >>>>>>>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>
>> >>
>> >>
>>
>>
>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
yes David, consistently. but I don't see stacktraces.
Now, looking at the code, I see that this stacktrace is logged in DEBUG:
final void dumpThreads()
{
try
{
String dump = new ThreadDump().call();
log( LogService.LOG_DEBUG, dump, null );
So, I will activate DEBUG and provide the stacktrace.
But is this a bug to log this stacktrace in DEBUG ?
I mean: should it be logged in WARN, instead of DEBUG ?
/pierre
On Tue, Oct 29, 2013 at 4:28 PM, David Jencks <da...@yahoo.com>wrote:
> Hi Pierre,
>
> I think there should be a thread dump in the log to go with this message.
> If there is could you send it to me or attach it to FELIX-4297?
>
> Does this happen consistently?
>
> many thanks
> david jencks
>
> On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hi David;
> >
> > 1) Every integration tests are passing OK.
> >
> > Regarding the OOM, I believe that the out of memory is likely to be cause
> > by the following load tests, which are running in DEBUG mode:
> >
> >
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> > src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
> > src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
> >
> >
> > So, I just added this in each files (in static initializers):
> >
> > DS_LOGLEVEL = "warn";
> >
> > And I have no more OOM, with this nice test result message:
> >
> > Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
> > [INFO] BUILD SUCCESS
> >
> >
> >
> > 2) Now, I did again a non regression tests with our applications, and I'm
> > seeing a new WARN message (but it does not seem to prevent the
> application
> > to be correctly initialized: all components are in the end satisfied):
> >
> > (if you believe that it's now time to release, then you can go ahead, and
> > we'll then investigate this new issue after the release ... I let you
> > decide)
> >
> > ->
> >
> > 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
> > pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
> > [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)] DependencyManager
> :
> > invokeBindMethod : timeout on open latch newtcpprocessor
> >
> >
> >
> >
> > kind regards;
> > /Pierre
> >
> >
> > On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <david_jencks@yahoo.com
> >wrote:
> >
> >> Pierre,
> >>
> >> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the
> >> problems I found (for 2). I don't see the OOM often enough to have any
> >> confidence that anything I do would actually fix it, so I'm inclined to
> do
> >> nothing. Is that OK with you?
> >>
> >> Unless you can find some more problems :-) I'm planning to try another
> >> release when the config admin 1.8 gets to maven central. I'm going to
> >> update the pom to normally run against the CA 1.8 version supporting R5
> and
> >> change the profile so running against R4 requires specifying profiles
> >> explicitly.
> >>
> >> thanks again!
> >> david jencks
> >>
> >> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com>
> wrote:
> >>
> >>> Hi Pierre,
> >>>
> >>> Much better to find these problems before a release than just after!
> >>>
> >>> I saw an OOM once recently but haven't been able to reproduce it.
> >>>
> >>> I'm looking into the NPE. I think I see the timing hole it is using
> but
> >> need to think about it some more.
> >>>
> >>> many thanks!
> >>> david jencks
> >>>
> >>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
> >> wrote:
> >>>
> >>>> Hi David,
> >>>>
> >>>> Looking at our configurator component we are currently using (but we
> >> will fix it in order to use the multi-location "?"), I see this:
> >>>>
> >>>> void configure(String pid, Dictionary pidConf) {
> >>>> Configuration config = getConfiguration(_pid, null);
> >>>> if (config.getBundleLocation() != null) {
> >>>> config.setBundleLocation(null);
> >>>> }
> >>>> config.update(pidConf);
> >>>> }
> >>>>
> >>>> So I believe that you are getting a null configuration because there
> is
> >> a short window between the setBundleLocation(null) (at this point, the
> >> configuration is null) and the config.update(pidConf) call ...
> >>>>
> >>>> So, the good news is that I'm not having anymore some NPE using your
> >> latest commits :-) and I think our application is now fully operational.
> >>>>
> >>>> but ... (please don't start to abominate me ) now, in order to do a
> >> final check, I restarted the integration tests and there is still two
> >> problems:
> >>>>
> >>>> 1) I'm sometimes getting some out of memory errors: this is probably
> >> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
> >> currently configured in DEBUG mode ?
> >>>>
> >>>> 2) I ran the tests two times, and the second time, I got this
> exception
> >> with the failing
> >>>> Felix3680_2Test:
> >>>>
> >>>>
> >>
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
> >> Time elapsed: 36.597 sec <<< ERROR!
> >>>> java.lang.NullPointerException
> >>>> at
> >>
> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> >>>> at
> >>
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> >>>> at
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> >>>> at
> >>
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> >>>> 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:4260)
> >>>> 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:148)
> >>>> at
> >>
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> >>>> at
> >>
> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> >>>> at
> >>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >>>> at
> >>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >>>> at java.lang.Thread.run(Thread.java:722)
> >>>>
> >>>> Are you also getting this exception ?
> >>>>
> >>>> thanks
> >>>>
> >>>> /Pierre
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <david_jencks@yahoo.com
> >
> >> wrote:
> >>>> Hi PIerre,
> >>>>
> >>>> Looking at the CA spec it looks like CA is supposed to send out
> >> CM_LOCATION_CHANGED events even before any properties are set when
> >> setBundleLocation is called. I added some code to ignore these events.
> >> Note that DS is "reserving" the configurations for (one of) the
> >> component(s) that will be consuming them by calling
> getConfiguration(pid).
> >>>>
> >>>> I do wonder how the location to something non-null on your
> >> configurations before the properties are set.
> >>>>
> >>>> Waiting for the next bug :-)
> >>>>
> >>>> thanks
> >>>> david jencks
> >>>>
> >>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
> >> wrote:
> >>>>
> >>>>> Hello David,
> >>>>>
> >>>>> The code we are using to configure our components is old, at at the
> >> time we wrote it, configadmin was not supporting multi-location. But I
> do
> >> agree, we can now use the "?" multi-location.
> >>>>>
> >>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
> >> always):
> >>>>>
> >>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
> >> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >> configuration event to [org.osgi.service.cm.ConfigurationListener,
> id=102,
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>
> >>>>> java.lang.NullPointerException
> >>>>> at
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>> at
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>> at
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> >>>>> at
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>> at
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>> at
> >> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>
> >>>>>
> >>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
> >> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct,
> then
> >> Is this a normal behavior ?
> >>>>>
> >>>>> This is strange; perhaps I shall start a new integration test ?
> >>>>>
> >>>>> /Pierre
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <
> david_jencks@yahoo.com>
> >> wrote:
> >>>>> Hi Pierre,
> >>>>>
> >>>>> This pointed out a logic error I introduced for Felix 3651. I opened
> >> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
> >> found which I think explains the NPE. Could you check this?
> >>>>>
> >>>>> Could I ask what you are trying to do by setting the bundleLocation
> to
> >> null? If you want to allow any bundle to receive the configuration you
> >> could use multi-location support and set the location to "?" With the
> code
> >> you have now, if the configuration is already in use by a DS component,
> the
> >> location changed event will result in the bundle location being reset
> back
> >> to what it was.
> >>>>>
> >>>>> thanks!
> >>>>> david jencks
> >>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
> >> wrote:
> >>>>>
> >>>>>> Hi David,
> >>>>>>
> >>>>>> thanks; The fix is fixing the problem :-)
> >>>>>>
> >>>>>> but ... there's now a new different problem: i'm now sometimes
> >> getting this
> >>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >>>>>>
> >>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire
> ConfigurationEvent:
> >>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
> >> id=102,
> >>>>>>
> >>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>>>
> >>>>>> java.lang.NullPointerException
> >>>>>> at
> >>>>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>>>> at
> >>>>>>
> >>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>>>> at
> >>>>>>
> >>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> >>>>>> at
> >>>>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>>>> at
> >>>>>>
> >>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>>>> at
> >> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>>>> at java.lang.Thread.run(Thread.java:722)
> >>>>>>
> >>>>>> Perhaps a new jira issue shall be opened ?
> >>>>>>
> >>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
> >>>>>> application, we populate configuration admin by doing something like
> >> this:
> >>>>>>
> >>>>>> Configuration cfg = cm.getConfiguration(pid, null)
> >>>>>> if (config.getBundleLocation() != null) {
> >>>>>> config.setBundleLocation(null);
> >>>>>> }
> >>>>>>
> >>>>>> The setBundleLocation(null) is probably useless, but this leads to a
> >>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the
> NPE.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
> >> wrote:
> >>>>>>> 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
> >>>>>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Hi Pierre,
I think there should be a thread dump in the log to go with this message. If there is could you send it to me or attach it to FELIX-4297?
Does this happen consistently?
many thanks
david jencks
On Oct 29, 2013, at 3:43 AM, Pierre De Rop <pi...@gmail.com> wrote:
> Hi David;
>
> 1) Every integration tests are passing OK.
>
> Regarding the OOM, I believe that the out of memory is likely to be cause
> by the following load tests, which are running in DEBUG mode:
>
> src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
> src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
> src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
>
>
> So, I just added this in each files (in static initializers):
>
> DS_LOGLEVEL = "warn";
>
> And I have no more OOM, with this nice test result message:
>
> Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
> [INFO] BUILD SUCCESS
>
>
>
> 2) Now, I did again a non regression tests with our applications, and I'm
> seeing a new WARN message (but it does not seem to prevent the application
> to be correctly initialized: all components are in the end satisfied):
>
> (if you believe that it's now time to release, then you can go ahead, and
> we'll then investigate this new issue after the release ... I let you
> decide)
>
> ->
>
> 2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
> pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
> [com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)] DependencyManager :
> invokeBindMethod : timeout on open latch newtcpprocessor
>
>
>
>
> kind regards;
> /Pierre
>
>
> On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <da...@yahoo.com>wrote:
>
>> Pierre,
>>
>> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the
>> problems I found (for 2). I don't see the OOM often enough to have any
>> confidence that anything I do would actually fix it, so I'm inclined to do
>> nothing. Is that OK with you?
>>
>> Unless you can find some more problems :-) I'm planning to try another
>> release when the config admin 1.8 gets to maven central. I'm going to
>> update the pom to normally run against the CA 1.8 version supporting R5 and
>> change the profile so running against R4 requires specifying profiles
>> explicitly.
>>
>> thanks again!
>> david jencks
>>
>> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com> wrote:
>>
>>> Hi Pierre,
>>>
>>> Much better to find these problems before a release than just after!
>>>
>>> I saw an OOM once recently but haven't been able to reproduce it.
>>>
>>> I'm looking into the NPE. I think I see the timing hole it is using but
>> need to think about it some more.
>>>
>>> many thanks!
>>> david jencks
>>>
>>> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
>> wrote:
>>>
>>>> Hi David,
>>>>
>>>> Looking at our configurator component we are currently using (but we
>> will fix it in order to use the multi-location "?"), I see this:
>>>>
>>>> void configure(String pid, Dictionary pidConf) {
>>>> Configuration config = getConfiguration(_pid, null);
>>>> if (config.getBundleLocation() != null) {
>>>> config.setBundleLocation(null);
>>>> }
>>>> config.update(pidConf);
>>>> }
>>>>
>>>> So I believe that you are getting a null configuration because there is
>> a short window between the setBundleLocation(null) (at this point, the
>> configuration is null) and the config.update(pidConf) call ...
>>>>
>>>> So, the good news is that I'm not having anymore some NPE using your
>> latest commits :-) and I think our application is now fully operational.
>>>>
>>>> but ... (please don't start to abominate me ) now, in order to do a
>> final check, I restarted the integration tests and there is still two
>> problems:
>>>>
>>>> 1) I'm sometimes getting some out of memory errors: this is probably
>> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
>> currently configured in DEBUG mode ?
>>>>
>>>> 2) I ran the tests two times, and the second time, I got this exception
>> with the failing
>>>> Felix3680_2Test:
>>>>
>>>>
>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
>> Time elapsed: 36.597 sec <<< ERROR!
>>>> java.lang.NullPointerException
>>>> at
>> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>>>> at
>> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>>>> at
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>>>> at
>> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>>>> 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:4260)
>>>> 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:148)
>>>> at
>> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>>>> at
>> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>>>> at
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>>>> at
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>>>> at java.lang.Thread.run(Thread.java:722)
>>>>
>>>> Are you also getting this exception ?
>>>>
>>>> thanks
>>>>
>>>> /Pierre
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>> Hi PIerre,
>>>>
>>>> Looking at the CA spec it looks like CA is supposed to send out
>> CM_LOCATION_CHANGED events even before any properties are set when
>> setBundleLocation is called. I added some code to ignore these events.
>> Note that DS is "reserving" the configurations for (one of) the
>> component(s) that will be consuming them by calling getConfiguration(pid).
>>>>
>>>> I do wonder how the location to something non-null on your
>> configurations before the properties are set.
>>>>
>>>> Waiting for the next bug :-)
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
>> wrote:
>>>>
>>>>> Hello David,
>>>>>
>>>>> The code we are using to configure our components is old, at at the
>> time we wrote it, configadmin was not supporting multi-location. But I do
>> agree, we can now use the "?" multi-location.
>>>>>
>>>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
>> always):
>>>>>
>>>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>
>>>>> java.lang.NullPointerException
>>>>> at
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>> at
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>> at
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>>>>> at
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>> at
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>> at
>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>
>>>>>
>>>>> I'm not sure, but it seems that ConfigAdmin is providing a null
>> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then
>> Is this a normal behavior ?
>>>>>
>>>>> This is strange; perhaps I shall start a new integration test ?
>>>>>
>>>>> /Pierre
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com>
>> wrote:
>>>>> Hi Pierre,
>>>>>
>>>>> This pointed out a logic error I introduced for Felix 3651. I opened
>> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
>> found which I think explains the NPE. Could you check this?
>>>>>
>>>>> Could I ask what you are trying to do by setting the bundleLocation to
>> null? If you want to allow any bundle to receive the configuration you
>> could use multi-location support and set the location to "?" With the code
>> you have now, if the configuration is already in use by a DS component, the
>> location changed event will result in the bundle location being reset back
>> to what it was.
>>>>>
>>>>> thanks!
>>>>> david jencks
>>>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
>> wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> thanks; The fix is fixing the problem :-)
>>>>>>
>>>>>> but ... there's now a new different problem: i'm now sometimes
>> getting this
>>>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>>>>>>
>>>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
>>>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
>> id=102,
>>>>>>
>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>>>
>>>>>> java.lang.NullPointerException
>>>>>> at
>>>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>>>> at
>>>>>>
>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>>>> at
>>>>>>
>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>>>>>> at
>>>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>>>> at
>>>>>>
>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>>>> at
>> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>>>> at java.lang.Thread.run(Thread.java:722)
>>>>>>
>>>>>> Perhaps a new jira issue shall be opened ?
>>>>>>
>>>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>>>>>> application, we populate configuration admin by doing something like
>> this:
>>>>>>
>>>>>> Configuration cfg = cm.getConfiguration(pid, null)
>>>>>> if (config.getBundleLocation() != null) {
>>>>>> config.setBundleLocation(null);
>>>>>> }
>>>>>>
>>>>>> The setBundleLocation(null) is probably useless, but this leads to a
>>>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
>> wrote:
>>>>>>> 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 <pi...@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
>>>>>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David;
1) Every integration tests are passing OK.
Regarding the OOM, I believe that the out of memory is likely to be cause
by the following load tests, which are running in DEBUG mode:
src/test/java/org/apache/felix/scr/integration/ComponentConcurrencyTest.java
src/test/java/org/apache/felix/scr/integration/Felix3680Test.java
src/test/java/org/apache/felix/scr/integration/Felix3680_2Test.java
So, I just added this in each files (in static initializers):
DS_LOGLEVEL = "warn";
And I have no more OOM, with this nice test result message:
Tests run: 103, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS
2) Now, I did again a non regression tests with our applications, and I'm
seeing a new WARN message (but it does not seem to prevent the application
to be correctly initialized: all components are in the end satisfied):
(if you believe that it's now time to release, then you can go ahead, and
we'll then investigate this new issue after the release ... I let you
decide)
->
2013-10-29 11:10:02,487 CM Event Dispatcher (Fire ConfigurationEvent:
pid=com.alcatel.as.ioh.impl.server.ServerFactoryImpl) ERROR osgi -
[com.alcatel.as.ioh.impl.server.ServerFactoryImpl(91)] DependencyManager :
invokeBindMethod : timeout on open latch newtcpprocessor
kind regards;
/Pierre
On Tue, Oct 29, 2013 at 12:13 AM, David Jencks <da...@yahoo.com>wrote:
> Pierre,
>
> I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the
> problems I found (for 2). I don't see the OOM often enough to have any
> confidence that anything I do would actually fix it, so I'm inclined to do
> nothing. Is that OK with you?
>
> Unless you can find some more problems :-) I'm planning to try another
> release when the config admin 1.8 gets to maven central. I'm going to
> update the pom to normally run against the CA 1.8 version supporting R5 and
> change the profile so running against R4 requires specifying profiles
> explicitly.
>
> thanks again!
> david jencks
>
> On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com> wrote:
>
> > Hi Pierre,
> >
> > Much better to find these problems before a release than just after!
> >
> > I saw an OOM once recently but haven't been able to reproduce it.
> >
> > I'm looking into the NPE. I think I see the timing hole it is using but
> need to think about it some more.
> >
> > many thanks!
> > david jencks
> >
> > On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >
> >> Hi David,
> >>
> >> Looking at our configurator component we are currently using (but we
> will fix it in order to use the multi-location "?"), I see this:
> >>
> >> void configure(String pid, Dictionary pidConf) {
> >> Configuration config = getConfiguration(_pid, null);
> >> if (config.getBundleLocation() != null) {
> >> config.setBundleLocation(null);
> >> }
> >> config.update(pidConf);
> >> }
> >>
> >> So I believe that you are getting a null configuration because there is
> a short window between the setBundleLocation(null) (at this point, the
> configuration is null) and the config.update(pidConf) call ...
> >>
> >> So, the good news is that I'm not having anymore some NPE using your
> latest commits :-) and I think our application is now fully operational.
> >>
> >> but ... (please don't start to abominate me ) now, in order to do a
> final check, I restarted the integration tests and there is still two
> problems:
> >>
> >> 1) I'm sometimes getting some out of memory errors: this is probably
> caused by the ComponentConcurrencyTest/Felix3680Test tests, which are
> currently configured in DEBUG mode ?
> >>
> >> 2) I ran the tests two times, and the second time, I got this exception
> with the failing
> >> Felix3680_2Test:
> >>
> >>
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
> Time elapsed: 36.597 sec <<< ERROR!
> >> java.lang.NullPointerException
> >> at
> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> >> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> >> at
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> >> at
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> >> 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:4260)
> >> 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:148)
> >> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> >> at
> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> >> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> >> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> >> at java.lang.Thread.run(Thread.java:722)
> >>
> >> Are you also getting this exception ?
> >>
> >> thanks
> >>
> >> /Pierre
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com>
> wrote:
> >> Hi PIerre,
> >>
> >> Looking at the CA spec it looks like CA is supposed to send out
> CM_LOCATION_CHANGED events even before any properties are set when
> setBundleLocation is called. I added some code to ignore these events.
> Note that DS is "reserving" the configurations for (one of) the
> component(s) that will be consuming them by calling getConfiguration(pid).
> >>
> >> I do wonder how the location to something non-null on your
> configurations before the properties are set.
> >>
> >> Waiting for the next bug :-)
> >>
> >> thanks
> >> david jencks
> >>
> >> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >>
> >>> Hello David,
> >>>
> >>> The code we are using to configure our components is old, at at the
> time we wrote it, configadmin was not supporting multi-location. But I do
> agree, we can now use the "?" multi-location.
> >>>
> >>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not
> always):
> >>>
> >>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>
> >>> java.lang.NullPointerException
> >>> at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>> at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>> at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> >>> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>> at java.lang.Thread.run(Thread.java:722)
> >>>
> >>>
> >>> I'm not sure, but it seems that ConfigAdmin is providing a null
> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then
> Is this a normal behavior ?
> >>>
> >>> This is strange; perhaps I shall start a new integration test ?
> >>>
> >>> /Pierre
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com>
> wrote:
> >>> Hi Pierre,
> >>>
> >>> This pointed out a logic error I introduced for Felix 3651. I opened
> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
> found which I think explains the NPE. Could you check this?
> >>>
> >>> Could I ask what you are trying to do by setting the bundleLocation to
> null? If you want to allow any bundle to receive the configuration you
> could use multi-location support and set the location to "?" With the code
> you have now, if the configuration is already in use by a DS component, the
> location changed event will result in the bundle location being reset back
> to what it was.
> >>>
> >>> thanks!
> >>> david jencks
> >>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >>>
> >>>> Hi David,
> >>>>
> >>>> thanks; The fix is fixing the problem :-)
> >>>>
> >>>> but ... there's now a new different problem: i'm now sometimes
> getting this
> >>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >>>>
> >>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> >>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> >>>> configuration event to [org.osgi.service.cm.ConfigurationListener,
> id=102,
> >>>>
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >>>>
> >>>> java.lang.NullPointerException
> >>>> at
> >>>>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> >>>> at
> >>>>
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> >>>> at
> >>>>
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> >>>> at
> >>>>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> >>>> at
> >>>>
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> >>>> at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> >>>> at java.lang.Thread.run(Thread.java:722)
> >>>>
> >>>> Perhaps a new jira issue shall be opened ?
> >>>>
> >>>> I think we are getting a CM_LOCATION_CHANGED event because in our
> >>>> application, we populate configuration admin by doing something like
> this:
> >>>>
> >>>> Configuration cfg = cm.getConfiguration(pid, null)
> >>>> if (config.getBundleLocation() != null) {
> >>>> config.setBundleLocation(null);
> >>>> }
> >>>>
> >>>> The setBundleLocation(null) is probably useless, but this leads to a
> >>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
> wrote:
> >>>>> 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 <pi...@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
> >>>>>>>>
> >>>
> >>>
> >>
> >>
> >
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Pierre,
I opened https://issues.apache.org/jira/browse/FELIX-4297 and fixed the problems I found (for 2). I don't see the OOM often enough to have any confidence that anything I do would actually fix it, so I'm inclined to do nothing. Is that OK with you?
Unless you can find some more problems :-) I'm planning to try another release when the config admin 1.8 gets to maven central. I'm going to update the pom to normally run against the CA 1.8 version supporting R5 and change the profile so running against R4 requires specifying profiles explicitly.
thanks again!
david jencks
On Oct 28, 2013, at 12:24 AM, David Jencks <da...@yahoo.com> wrote:
> Hi Pierre,
>
> Much better to find these problems before a release than just after!
>
> I saw an OOM once recently but haven't been able to reproduce it.
>
> I'm looking into the NPE. I think I see the timing hole it is using but need to think about it some more.
>
> many thanks!
> david jencks
>
> On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
>> Hi David,
>>
>> Looking at our configurator component we are currently using (but we will fix it in order to use the multi-location "?"), I see this:
>>
>> void configure(String pid, Dictionary pidConf) {
>> Configuration config = getConfiguration(_pid, null);
>> if (config.getBundleLocation() != null) {
>> config.setBundleLocation(null);
>> }
>> config.update(pidConf);
>> }
>>
>> So I believe that you are getting a null configuration because there is a short window between the setBundleLocation(null) (at this point, the configuration is null) and the config.update(pidConf) call ...
>>
>> So, the good news is that I'm not having anymore some NPE using your latest commits :-) and I think our application is now fully operational.
>>
>> but ... (please don't start to abominate me ) now, in order to do a final check, I restarted the integration tests and there is still two problems:
>>
>> 1) I'm sometimes getting some out of memory errors: this is probably caused by the ComponentConcurrencyTest/Felix3680Test tests, which are currently configured in DEBUG mode ?
>>
>> 2) I ran the tests two times, and the second time, I got this exception with the failing
>> Felix3680_2Test:
>>
>> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test) Time elapsed: 36.597 sec <<< ERROR!
>> java.lang.NullPointerException
>> at org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
>> at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
>> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
>> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
>> 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:4260)
>> 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:148)
>> at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
>> at org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
>> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>> at java.lang.Thread.run(Thread.java:722)
>>
>> Are you also getting this exception ?
>>
>> thanks
>>
>> /Pierre
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com> wrote:
>> Hi PIerre,
>>
>> Looking at the CA spec it looks like CA is supposed to send out CM_LOCATION_CHANGED events even before any properties are set when setBundleLocation is called. I added some code to ignore these events. Note that DS is "reserving" the configurations for (one of) the component(s) that will be consuming them by calling getConfiguration(pid).
>>
>> I do wonder how the location to something non-null on your configurations before the properties are set.
>>
>> Waiting for the next bug :-)
>>
>> thanks
>> david jencks
>>
>> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>
>>> Hello David,
>>>
>>> The code we are using to configure our components is old, at at the time we wrote it, configadmin was not supporting multi-location. But I do agree, we can now use the "?" multi-location.
>>>
>>> Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
>>>
>>> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent: pid=sipagent) ERROR osgi - [43] Unexpected problem delivering configuration event to [org.osgi.service.cm.ConfigurationListener, id=102, bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>
>>> java.lang.NullPointerException
>>> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>> at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
>>> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>> at java.lang.Thread.run(Thread.java:722)
>>>
>>>
>>> I'm not sure, but it seems that ConfigAdmin is providing a null dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a normal behavior ?
>>>
>>> This is strange; perhaps I shall start a new integration test ?
>>>
>>> /Pierre
>>>
>>>
>>>
>>>
>>> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com> wrote:
>>> Hi Pierre,
>>>
>>> This pointed out a logic error I introduced for Felix 3651. I opened https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found which I think explains the NPE. Could you check this?
>>>
>>> Could I ask what you are trying to do by setting the bundleLocation to null? If you want to allow any bundle to receive the configuration you could use multi-location support and set the location to "?" With the code you have now, if the configuration is already in use by a DS component, the location changed event will result in the bundle location being reset back to what it was.
>>>
>>> thanks!
>>> david jencks
>>> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
>>>
>>>> Hi David,
>>>>
>>>> thanks; The fix is fixing the problem :-)
>>>>
>>>> but ... there's now a new different problem: i'm now sometimes getting this
>>>> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>>>>
>>>> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
>>>> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
>>>> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
>>>> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>>>>
>>>> java.lang.NullPointerException
>>>> at
>>>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
>>>> at
>>>> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
>>>> at
>>>> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
>>>> at
>>>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
>>>> at
>>>> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
>>>> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
>>>> at java.lang.Thread.run(Thread.java:722)
>>>>
>>>> Perhaps a new jira issue shall be opened ?
>>>>
>>>> I think we are getting a CM_LOCATION_CHANGED event because in our
>>>> application, we populate configuration admin by doing something like this:
>>>>
>>>> Configuration cfg = cm.getConfiguration(pid, null)
>>>> if (config.getBundleLocation() != null) {
>>>> config.setBundleLocation(null);
>>>> }
>>>>
>>>> The setBundleLocation(null) is probably useless, but this leads to a
>>>> CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
>>>>> 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 <pi...@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 <pi...@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
>>>>>>>>
>>>
>>>
>>
>>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Hi Pierre,
Much better to find these problems before a release than just after!
I saw an OOM once recently but haven't been able to reproduce it.
I'm looking into the NPE. I think I see the timing hole it is using but need to think about it some more.
many thanks!
david jencks
On Oct 27, 2013, at 2:58 AM, Pierre De Rop <pi...@gmail.com> wrote:
> Hi David,
>
> Looking at our configurator component we are currently using (but we will fix it in order to use the multi-location "?"), I see this:
>
> void configure(String pid, Dictionary pidConf) {
> Configuration config = getConfiguration(_pid, null);
> if (config.getBundleLocation() != null) {
> config.setBundleLocation(null);
> }
> config.update(pidConf);
> }
>
> So I believe that you are getting a null configuration because there is a short window between the setBundleLocation(null) (at this point, the configuration is null) and the config.update(pidConf) call ...
>
> So, the good news is that I'm not having anymore some NPE using your latest commits :-) and I think our application is now fully operational.
>
> but ... (please don't start to abominate me ) now, in order to do a final check, I restarted the integration tests and there is still two problems:
>
> 1) I'm sometimes getting some out of memory errors: this is probably caused by the ComponentConcurrencyTest/Felix3680Test tests, which are currently configured in DEBUG mode ?
>
> 2) I ran the tests two times, and the second time, I got this exception with the failing
> Felix3680_2Test:
>
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test) Time elapsed: 36.597 sec <<< ERROR!
> java.lang.NullPointerException
> at org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> at org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> at org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> 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:4260)
> 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:148)
> at org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> at org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> Are you also getting this exception ?
>
> thanks
>
> /Pierre
>
>
>
>
>
>
>
> On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com> wrote:
> Hi PIerre,
>
> Looking at the CA spec it looks like CA is supposed to send out CM_LOCATION_CHANGED events even before any properties are set when setBundleLocation is called. I added some code to ignore these events. Note that DS is "reserving" the configurations for (one of) the component(s) that will be consuming them by calling getConfiguration(pid).
>
> I do wonder how the location to something non-null on your configurations before the properties are set.
>
> Waiting for the next bug :-)
>
> thanks
> david jencks
>
> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hello David,
> >
> > The code we are using to configure our components is old, at at the time we wrote it, configadmin was not supporting multi-location. But I do agree, we can now use the "?" multi-location.
> >
> > Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
> >
> > 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent: pid=sipagent) ERROR osgi - [43] Unexpected problem delivering configuration event to [org.osgi.service.cm.ConfigurationListener, id=102, bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >
> > java.lang.NullPointerException
> > at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> > at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > at java.lang.Thread.run(Thread.java:722)
> >
> >
> > I'm not sure, but it seems that ConfigAdmin is providing a null dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a normal behavior ?
> >
> > This is strange; perhaps I shall start a new integration test ?
> >
> > /Pierre
> >
> >
> >
> >
> > On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com> wrote:
> > Hi Pierre,
> >
> > This pointed out a logic error I introduced for Felix 3651. I opened https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found which I think explains the NPE. Could you check this?
> >
> > Could I ask what you are trying to do by setting the bundleLocation to null? If you want to allow any bundle to receive the configuration you could use multi-location support and set the location to "?" With the code you have now, if the configuration is already in use by a DS component, the location changed event will result in the bundle location being reset back to what it was.
> >
> > thanks!
> > david jencks
> > On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
> >
> > > Hi David,
> > >
> > > thanks; The fix is fixing the problem :-)
> > >
> > > but ... there's now a new different problem: i'm now sometimes getting this
> > > NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> > >
> > > 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> > > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> > > configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
> > > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> > >
> > > java.lang.NullPointerException
> > > at
> > > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > > at
> > > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > > at
> > > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> > > at
> > > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > > at
> > > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > > at java.lang.Thread.run(Thread.java:722)
> > >
> > > Perhaps a new jira issue shall be opened ?
> > >
> > > I think we are getting a CM_LOCATION_CHANGED event because in our
> > > application, we populate configuration admin by doing something like this:
> > >
> > > Configuration cfg = cm.getConfiguration(pid, null)
> > > if (config.getBundleLocation() != null) {
> > > config.setBundleLocation(null);
> > > }
> > >
> > > The setBundleLocation(null) is probably useless, but this leads to a
> > > CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
> > >> 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 <pi...@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 <pi...@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
> > >>>>>
> >
> >
>
>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David,
Looking at our configurator component we are currently using (but we will
fix it in order to use the multi-location "?"), I see this:
void configure(String pid, Dictionary pidConf) {
Configuration config = getConfiguration(_pid, null);
if (config.getBundleLocation() != null) {
config.setBundleLocation(null);
}
config.update(pidConf);
}
So I believe that you are getting a null configuration because there is a
short window between the setBundleLocation(null) (at this point, the
configuration is null) and the config.update(pidConf) call ...
So, the good news is that I'm not having anymore some NPE using your latest
commits :-) and I think our application is now fully operational.
but ... (please don't start to abominate me [?]) now, in order to do a
final check, I restarted the integration tests and there is still two
problems:
1) I'm sometimes getting some out of memory errors: this is probably caused
by the ComponentConcurrencyTest/Felix3680Test tests, which are currently
configured in DEBUG mode ?
2) I ran the tests two times, and the second time, I got this exception
with the failing
Felix3680_2Test:
test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
Time elapsed: 36.597 sec <<< ERROR!
java.lang.NullPointerException
at
org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
at
org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
at
org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
at
org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
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:4260)
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:148)
at
org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
at
org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)
Are you also getting this exception ?
thanks
/Pierre
On Sat, Oct 26, 2013 at 6:34 PM, David Jencks <da...@yahoo.com>wrote:
> Hi PIerre,
>
> Looking at the CA spec it looks like CA is supposed to send out
> CM_LOCATION_CHANGED events even before any properties are set when
> setBundleLocation is called. I added some code to ignore these events.
> Note that DS is "reserving" the configurations for (one of) the
> component(s) that will be consuming them by calling getConfiguration(pid).
>
> I do wonder how the location to something non-null on your configurations
> before the properties are set.
>
> Waiting for the next bug :-)
>
> thanks
> david jencks
>
> On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hello David,
> >
> > The code we are using to configure our components is old, at at the time
> we wrote it, configadmin was not supporting multi-location. But I do agree,
> we can now use the "?" multi-location.
> >
> > Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
> >
> > 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >
> > java.lang.NullPointerException
> > at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> > at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > at java.lang.Thread.run(Thread.java:722)
> >
> >
> > I'm not sure, but it seems that ConfigAdmin is providing a null
> dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then
> Is this a normal behavior ?
> >
> > This is strange; perhaps I shall start a new integration test ?
> >
> > /Pierre
> >
> >
> >
> >
> > On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com>
> wrote:
> > Hi Pierre,
> >
> > This pointed out a logic error I introduced for Felix 3651. I opened
> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
> found which I think explains the NPE. Could you check this?
> >
> > Could I ask what you are trying to do by setting the bundleLocation to
> null? If you want to allow any bundle to receive the configuration you
> could use multi-location support and set the location to "?" With the code
> you have now, if the configuration is already in use by a DS component, the
> location changed event will result in the bundle location being reset back
> to what it was.
> >
> > thanks!
> > david jencks
> > On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com>
> wrote:
> >
> > > Hi David,
> > >
> > > thanks; The fix is fixing the problem :-)
> > >
> > > but ... there's now a new different problem: i'm now sometimes getting
> this
> > > NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> > >
> > > 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> > > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> > > configuration event to [org.osgi.service.cm.ConfigurationListener,
> id=102,
> > >
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> > >
> > > java.lang.NullPointerException
> > > at
> > >
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > > at
> > >
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > > at
> > >
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> > > at
> > >
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > > at
> > >
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > > at
> org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > > at java.lang.Thread.run(Thread.java:722)
> > >
> > > Perhaps a new jira issue shall be opened ?
> > >
> > > I think we are getting a CM_LOCATION_CHANGED event because in our
> > > application, we populate configuration admin by doing something like
> this:
> > >
> > > Configuration cfg = cm.getConfiguration(pid, null)
> > > if (config.getBundleLocation() != null) {
> > > config.setBundleLocation(null);
> > > }
> > >
> > > The setBundleLocation(null) is probably useless, but this leads to a
> > > CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
> wrote:
> > >> 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 <pi...@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 <pi...@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
> > >>>>>
> >
> >
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Hi PIerre,
Looking at the CA spec it looks like CA is supposed to send out CM_LOCATION_CHANGED events even before any properties are set when setBundleLocation is called. I added some code to ignore these events. Note that DS is "reserving" the configurations for (one of) the component(s) that will be consuming them by calling getConfiguration(pid).
I do wonder how the location to something non-null on your configurations before the properties are set.
Waiting for the next bug :-)
thanks
david jencks
On Oct 26, 2013, at 3:00 AM, Pierre De Rop <pi...@gmail.com> wrote:
> Hello David,
>
> The code we are using to configure our components is old, at at the time we wrote it, configadmin was not supporting multi-location. But I do agree, we can now use the "?" multi-location.
>
> Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
>
> 2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent: pid=sipagent) ERROR osgi - [43] Unexpected problem delivering configuration event to [org.osgi.service.cm.ConfigurationListener, id=102, bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>
> java.lang.NullPointerException
> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> at org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> at org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> at org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:722)
>
>
> I'm not sure, but it seems that ConfigAdmin is providing a null dictionary, when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a normal behavior ?
>
> This is strange; perhaps I shall start a new integration test ?
>
> /Pierre
>
>
>
>
> On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com> wrote:
> Hi Pierre,
>
> This pointed out a logic error I introduced for Felix 3651. I opened https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found which I think explains the NPE. Could you check this?
>
> Could I ask what you are trying to do by setting the bundleLocation to null? If you want to allow any bundle to receive the configuration you could use multi-location support and set the location to "?" With the code you have now, if the configuration is already in use by a DS component, the location changed event will result in the bundle location being reset back to what it was.
>
> thanks!
> david jencks
> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hi David,
> >
> > thanks; The fix is fixing the problem :-)
> >
> > but ... there's now a new different problem: i'm now sometimes getting this
> > NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >
> > 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> > configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
> > bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >
> > java.lang.NullPointerException
> > at
> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > at
> > org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > at
> > org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> > at
> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > at
> > org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > at java.lang.Thread.run(Thread.java:722)
> >
> > Perhaps a new jira issue shall be opened ?
> >
> > I think we are getting a CM_LOCATION_CHANGED event because in our
> > application, we populate configuration admin by doing something like this:
> >
> > Configuration cfg = cm.getConfiguration(pid, null)
> > if (config.getBundleLocation() != null) {
> > config.setBundleLocation(null);
> > }
> >
> > The setBundleLocation(null) is probably useless, but this leads to a
> > CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
> >
> >
> >
> >
> >
> >
> > On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
> >> 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 <pi...@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 <pi...@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
> >>>>>
>
>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hello David,
The code we are using to configure our components is old, at at the time we
wrote it, configadmin was not supporting multi-location. But I do agree, we
can now use the "?" multi-location.
Now, I'm sorry but I'm still seeing another NPE (sometimes, not always):
2013-10-26 11:45:44,209 CM Event Dispatcher (Fire ConfigurationEvent:
pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
java.lang.NullPointerException
at
org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
at
org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
at
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:344)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
at java.lang.Thread.run(Thread.java:722)
I'm not sure, but it seems that ConfigAdmin is providing a null dictionary,
when delivering a CM_LOCATION_CHANGED event ? if correct, then Is this a
normal behavior ?
This is strange; perhaps I shall start a new integration test ? [?]
/Pierre
On Sat, Oct 26, 2013 at 9:54 AM, David Jencks <da...@yahoo.com>wrote:
> Hi Pierre,
>
> This pointed out a logic error I introduced for Felix 3651. I opened
> https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I
> found which I think explains the NPE. Could you check this?
>
> Could I ask what you are trying to do by setting the bundleLocation to
> null? If you want to allow any bundle to receive the configuration you
> could use multi-location support and set the location to "?" With the code
> you have now, if the configuration is already in use by a DS component, the
> location changed event will result in the bundle location being reset back
> to what it was.
>
> thanks!
> david jencks
> On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
>
> > Hi David,
> >
> > thanks; The fix is fixing the problem :-)
> >
> > but ... there's now a new different problem: i'm now sometimes getting
> this
> > NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
> >
> > 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> > pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> > configuration event to [org.osgi.service.cm.ConfigurationListener,
> id=102,
> >
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
> >
> > java.lang.NullPointerException
> > at
> >
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> > at
> >
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> > at
> >
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> > at
> >
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> > at
> >
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> > at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> > at java.lang.Thread.run(Thread.java:722)
> >
> > Perhaps a new jira issue shall be opened ?
> >
> > I think we are getting a CM_LOCATION_CHANGED event because in our
> > application, we populate configuration admin by doing something like
> this:
> >
> > Configuration cfg = cm.getConfiguration(pid, null)
> > if (config.getBundleLocation() != null) {
> > config.setBundleLocation(null);
> > }
> >
> > The setBundleLocation(null) is probably useless, but this leads to a
> > CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
> >
> >
> >
> >
> >
> >
> > On Friday, October 25, 2013, David Jencks <da...@yahoo.com>
> wrote:
> >> 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 <pi...@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 <pi...@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
> >>>>>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
Hi Pierre,
This pointed out a logic error I introduced for Felix 3651. I opened https://issues.apache.org/jira/browse/FELIX-4293 and fixed the error I found which I think explains the NPE. Could you check this?
Could I ask what you are trying to do by setting the bundleLocation to null? If you want to allow any bundle to receive the configuration you could use multi-location support and set the location to "?" With the code you have now, if the configuration is already in use by a DS component, the location changed event will result in the bundle location being reset back to what it was.
thanks!
david jencks
On Oct 25, 2013, at 8:32 AM, Pierre De Rop <pi...@gmail.com> wrote:
> Hi David,
>
> thanks; The fix is fixing the problem :-)
>
> but ... there's now a new different problem: i'm now sometimes getting this
> NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
>
> 2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
> pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
> configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
> bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
>
> java.lang.NullPointerException
> at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
> at
> org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
> at
> org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
> at
> org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
> at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
> at java.lang.Thread.run(Thread.java:722)
>
> Perhaps a new jira issue shall be opened ?
>
> I think we are getting a CM_LOCATION_CHANGED event because in our
> application, we populate configuration admin by doing something like this:
>
> Configuration cfg = cm.getConfiguration(pid, null)
> if (config.getBundleLocation() != null) {
> config.setBundleLocation(null);
> }
>
> The setBundleLocation(null) is probably useless, but this leads to a
> CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
>
>
>
>
>
>
> On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
>> 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 <pi...@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 <pi...@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
>>>>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
Hi David,
thanks; The fix is fixing the problem :-)
but ... there's now a new different problem: i'm now sometimes getting this
NPE, after SCR is receiving a CM_LOCATION_CHANGED event:
2013-10-25 16:11:44,674 CM Event Dispatcher (Fire ConfigurationEvent:
pid=sipagent) ERROR osgi - [43] Unexpected problem delivering
configuration event to [org.osgi.service.cm.ConfigurationListener, id=102,
bundle=341/reference:file:/home/nxuser/pp/bundles/custo/org.apache.felix.scr.jar]
java.lang.NullPointerException
at
org.apache.felix.scr.impl.manager.ComponentFactoryImpl.getProperties(ComponentFactoryImpl.java:226)
at
org.apache.felix.scr.impl.manager.ComponentFactoryImpl.configurationUpdated(ComponentFactoryImpl.java:396)
at
org.apache.felix.scr.impl.config.ConfigurationSupport.configurationEvent(ConfigurationSupport.java:390)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.sendEvent(ConfigurationManager.java:2032)
at
org.apache.felix.cm.impl.ConfigurationManager$FireConfigurationEvent.run(ConfigurationManager.java:2002)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:103)
at java.lang.Thread.run(Thread.java:722)
Perhaps a new jira issue shall be opened ?
I think we are getting a CM_LOCATION_CHANGED event because in our
application, we populate configuration admin by doing something like this:
Configuration cfg = cm.getConfiguration(pid, null)
if (config.getBundleLocation() != null) {
config.setBundleLocation(null);
}
The setBundleLocation(null) is probably useless, but this leads to a
CM_LOCATION_CHANGED event, which then sometimes ends up with the NPE.
On Friday, October 25, 2013, David Jencks <da...@yahoo.com> wrote:
> 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 <pi...@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 <pi...@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
>>>>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
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 <pi...@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 <da...@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 <pi...@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 <pi...@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 <pi...@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" <da...@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
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
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 <da...@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 <pi...@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 <pi...@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 <pi...@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" <da...@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
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
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 <pi...@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 <da...@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 <pi...@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 <pi...@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" <da...@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
>>>>>>
>>>>
>>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
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 <da...@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 <pi...@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 <pi...@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" <da...@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
> >>>>
> >>
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
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 <pi...@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 <da...@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 <pi...@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" <da...@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
>>>>
>>
>>
Re: [DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
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 <da...@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 <pi...@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" <da...@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
> >>
>
>
Re: [DS] time for 1.8 release?
Posted by David Jencks <da...@yahoo.com>.
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 <pi...@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" <da...@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
>>
[DS] time for 1.8 release?
Posted by Pierre De Rop <pi...@gmail.com>.
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" <da...@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
>
Re: [DS] time for 1.8 release?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Hmm, sent prematurely and "xxxx" should really be an email address.
But I think, it is actually not required, since Felix committers should probably have enough karma to deploy.
Regards
Felix
Am 20.10.2013 um 09:15 schrieb Felix Meschberger:
> Hi David
>
> Cool ! Thanks a lot for this.
>
> I agree with cutting a release soon.
>
> As for release management: every committer can do and manage a release. For Nexus write access you may just write a message to xxxx to get access granted. Unfortunately updating the dist repo requires PMC memebership. But that is not an issue, just send me a signal and I can do that.
>
> Regards
> Felix
>
> Von meinem iPad gesendet
>
>> Am 20.10.2013 um 07:50 schrieb "David Jencks" <da...@yahoo.com>:
>>
>> 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
>>
Re: [DS] time for 1.8 release?
Posted by Felix Meschberger <fm...@adobe.com>.
Hi David
Cool ! Thanks a lot for this.
I agree with cutting a release soon.
As for release management: every committer can do and manage a release. For Nexus write access you may just write a message to xxxx to get access granted. Unfortunately updating the dist repo requires PMC memebership. But that is not an issue, just send me a signal and I can do that.
Regards
Felix
Von meinem iPad gesendet
> Am 20.10.2013 um 07:50 schrieb "David Jencks" <da...@yahoo.com>:
>
> 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
>