You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Pierre De Rop <pi...@gmail.com> on 2010/04/24 11:49:36 UTC
Issue with ConfigAdmin 1.2.4 ?
Hello everyone, and Felix;
I am using ConfigAdmin 1.2.4, and I have written a test case which is using
a ManagedServiceFactory, and consists in updating a Factory Configuration
object.
Something like:
Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
null);
cf.update(new Properties() {{ put("foo", "bar"); }});
And then, a little bit later, I update again the cf object, like this:
cf.update(new Properties() {{ put("foo", "bar2"); }});
So, most of the time, this test works fine. However, some times, the last
update seems to be missed, and I see the following CM logs:
[LogService/4] Scheduling task Update:
pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
[LogService/4] Running task Update:
pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
[LogService/4] Configuration
MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been updated,
nothing to be done anymore.
[LogService/4] Scheduling task Fire ConfigurationEvent:
pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
[LogService/4] Running task Fire ConfigurationEvent:
pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
So, I have checked if some pending issues were addressing this eventual
problem, and I came across the issue FELIX-1545.
So, my question is the following:
is my problem related to the FELIX-1545 issue ? if not, then should I open a
Jira issue ?
thanks;
/pierre
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Pierre,
On 25.08.2010 22:21, Pierre De Rop wrote:
> FWI, I just ran the dependency manager test cases (with your fixed CM
> version, and without my work around) -> and all tests are now passing
> perfectly.
> ... will vote +1 !
Exccellent. Good to hear. Thanks.
Regards
Felix
>
> thanks.
> /pierre
>
> On 27.04.2010 20:05, Pierre De Rop wrote:
> > Hello Felix,
> >
> > Thanks for your explanation.
> > After more investigations, I can now describe more specifically
> the issue I
> > am facing, and in my use case, it sounds like the most recent
> update (the
> > fifth in your previous example) is lost.
> >
> > It's not easy to explain, but here is what I am observing:
> >
> > 1) I have written to a junit test for dependency manager, which
> verifies
> > some stuff regarding dependency manager and config admin.
> >
> > 2) In this junit test, I first create a factory configuration, which
> > delivers an initial update to one given ManagedServiceFactory
> instance.
> >
> > 3) Now, in the "updated" method of my ManagedserviceFactory, I notify
> > another thread "T" in order to inform that the update has taken place
> > properly.
> > So far so good.
> >
> > 4) At that point in time, the ConfigurationManager.java class (in
> CM) has
> > returned from my ManagedServiceFactory.updated() method
> invocation, and is
> > about to set the configuration last updated time (in
> > ConfigurationManager.java, line 1531). This method will actually
> set the
> > last update time to the most recent last modification time (If my
> > understanding is correct).
> >
> > 5) But concurrently, the other thread "T" which has been notified
> from my
> > ManagedServiceFactory.updated() method is UPDATING the
> configuration ... so
> > the configuration last modification time is incremented.
> >
> > 6) Finally, the ConfigurationManager, line 1531, invokes the
> > config.setLastUpdatedTime(), which actually uses the last
> modification time
> > that has just been set in step 5) by the thread "T".
> >
> > 7) and when the update instigated from the thread "T" is about to be
> > processed by the UpdateThread (in CM), then the following test
> succeeds and
> > the update made by "T" is ignored:
> >
> > if ( lastModificationTime <=
> config.getLastUpdatedTime() )
> > {
> > log( LogService.LOG_DEBUG, "Configuration " +
> > config.getPid() + " at modification #"
> > + config.getLastModificationTime() + " has
> already
> > been updated to update #"
> > + config.getLastUpdatedTime() + ", nothing
> to be
> > done anymore.", null );
> > return;
> > }
> >
> >
> > So, here, it seems that we have lost the most recent update (made from
> > thread "T").
> > Am I correct with this explanation ?
> >
> > Now, I just read your last comment in issue 1545, where you
> propose to add a
> > third sequence number.
> > Would that third sequence number resolve my issue ?
> > I am not sure whether I understand the purpose of this third
> counter you
> > propose, can you please explain it ?
> >
> >
> > thanks;
> > /pierre
> >
> >
> > On Mon, Apr 26, 2010 at 9:44 AM, Felix Meschberger
> <fmeschbe@gmail.com <ma...@gmail.com>>wrote:
> >
> >> Hi,
> >>
> >> On 25.04.2010 22:57, Pierre De Rop wrote:
> >>> Then I have a junit test which reproduces the problem.
> >>> Would you like me to attach it to the FELIX-1545 issue ?
> >>
> >> This is very helpful. Thanks.
> >>
> >> I suspect the following is going on: The configuration is repeatedly
> >> updated and since delivery lags behind update, only the latest update
> >> state at the time of delivery is actually delivered.
> >>
> >> Consider for example 5 updates in succession. The first might be
> >> delivered, which delays the delivery thread. When the delivery thread
> >> takes the next update task from the queue, the most recent update
> (the
> >> fifth) is delivered. Updates 2-4 are not delivered.
> >>
> >> In the end it (theoretically) makes no difference. But I agree, that
> >> this is definitely not what is expected.
> >>
> >> So, I will have to refactor configuration delivery such that the
> actual
> >> update of each configuration is effectively delivered.
> >>
> >> Regards
> >> Felix
> >>
> >>
> >>>
> >>> Regards;
> >>> /pierre
> >>>
> >>>
> >>> On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger
> <fmeschbe@gmail.com <ma...@gmail.com>
> >>> wrote:
> >>>
> >>>> Hi Pierre,
> >>>>
> >>>> Yes, I am afraid that you run into the FELIX-1545 issue ...
> >>>>
> >>>> Regards
> >>>> Felix
> >>>>
> >>>> On 24.04.2010 11:49, Pierre De Rop wrote:
> >>>>> Hello everyone, and Felix;
> >>>>>
> >>>>> I am using ConfigAdmin 1.2.4, and I have written a test case
> which is
> >>>> using
> >>>>> a ManagedServiceFactory, and consists in updating a Factory
> >> Configuration
> >>>>> object.
> >>>>> Something like:
> >>>>>
> >>>>> Configuration cf =
> configAdmin.createFactoryConfiguration(m_factoryPid,
> >>>>> null);
> >>>>> cf.update(new Properties() {{ put("foo", "bar"); }});
> >>>>>
> >>>>> And then, a little bit later, I update again the cf object,
> like this:
> >>>>>
> >>>>> cf.update(new Properties() {{ put("foo", "bar2"); }});
> >>>>>
> >>>>> So, most of the time, this test works fine. However, some
> times, the
> >> last
> >>>>> update seems to be missed, and I see the following CM logs:
> >>>>>
> >>>>> [LogService/4] Scheduling task Update:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Running task Update:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Configuration
> >>>>> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
> >>>> updated,
> >>>>> nothing to be done anymore.
> >>>>> [LogService/4] Scheduling task Fire ConfigurationEvent:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Running task Fire ConfigurationEvent:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>>
> >>>>> So, I have checked if some pending issues were addressing this
> eventual
> >>>>> problem, and I came across the issue FELIX-1545.
> >>>>> So, my question is the following:
> >>>>>
> >>>>> is my problem related to the FELIX-1545 issue ? if not, then
> should I
> >>>> open a
> >>>>> Jira issue ?
> >>>>>
> >>>>> thanks;
> >>>>> /pierre
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Pierre De Rop <pi...@gmail.com>.
On Wed, Aug 25, 2010 at 8:40 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> Sorry for the long delay (caused by multiple distractions).
>
Hi Felix !
No problem for the delay. In my testcase, so far I was working around the
problem by placing some "sleep(500)" in the code ...
> I have finally committed your testcase for FELIX-1545 and implemented a
> fix for the problem. It turned out, that the fix was quite easy: instead
> of setting the last updated field to the current value of the last
> modified field it is now set to the value of the last modified field at
> the time the update was scheduled.
>
Ok.
>
> As a consequence the configuration updates are not missed any longer.
>
> After fixing a number of other bugs, too, I have now deployed a SNAPSHOT
> (1.2.7-20100825.182233-1) which you might want to test.
>
> I plan to cut a release candidate in a few days.
>
>
FWI, I just ran the dependency manager test cases (with your fixed CM
version, and without my work around) -> and all tests are now passing
perfectly.
... will vote +1 ! [?]
thanks.
/pierre
On 27.04.2010 20:05, Pierre De Rop wrote:
> > Hello Felix,
> >
> > Thanks for your explanation.
> > After more investigations, I can now describe more specifically the issue
> I
> > am facing, and in my use case, it sounds like the most recent update (the
> > fifth in your previous example) is lost.
> >
> > It's not easy to explain, but here is what I am observing:
> >
> > 1) I have written to a junit test for dependency manager, which verifies
> > some stuff regarding dependency manager and config admin.
> >
> > 2) In this junit test, I first create a factory configuration, which
> > delivers an initial update to one given ManagedServiceFactory instance.
> >
> > 3) Now, in the "updated" method of my ManagedserviceFactory, I notify
> > another thread "T" in order to inform that the update has taken place
> > properly.
> > So far so good.
> >
> > 4) At that point in time, the ConfigurationManager.java class (in CM) has
> > returned from my ManagedServiceFactory.updated() method invocation, and
> is
> > about to set the configuration last updated time (in
> > ConfigurationManager.java, line 1531). This method will actually set the
> > last update time to the most recent last modification time (If my
> > understanding is correct).
> >
> > 5) But concurrently, the other thread "T" which has been notified from my
> > ManagedServiceFactory.updated() method is UPDATING the configuration ...
> so
> > the configuration last modification time is incremented.
> >
> > 6) Finally, the ConfigurationManager, line 1531, invokes the
> > config.setLastUpdatedTime(), which actually uses the last modification
> time
> > that has just been set in step 5) by the thread "T".
> >
> > 7) and when the update instigated from the thread "T" is about to be
> > processed by the UpdateThread (in CM), then the following test succeeds
> and
> > the update made by "T" is ignored:
> >
> > if ( lastModificationTime <= config.getLastUpdatedTime()
> )
> > {
> > log( LogService.LOG_DEBUG, "Configuration " +
> > config.getPid() + " at modification #"
> > + config.getLastModificationTime() + " has
> already
> > been updated to update #"
> > + config.getLastUpdatedTime() + ", nothing to be
> > done anymore.", null );
> > return;
> > }
> >
> >
> > So, here, it seems that we have lost the most recent update (made from
> > thread "T").
> > Am I correct with this explanation ?
> >
> > Now, I just read your last comment in issue 1545, where you propose to
> add a
> > third sequence number.
> > Would that third sequence number resolve my issue ?
> > I am not sure whether I understand the purpose of this third counter you
> > propose, can you please explain it ?
> >
> >
> > thanks;
> > /pierre
> >
> >
> > On Mon, Apr 26, 2010 at 9:44 AM, Felix Meschberger <fmeschbe@gmail.com
> >wrote:
> >
> >> Hi,
> >>
> >> On 25.04.2010 22:57, Pierre De Rop wrote:
> >>> Then I have a junit test which reproduces the problem.
> >>> Would you like me to attach it to the FELIX-1545 issue ?
> >>
> >> This is very helpful. Thanks.
> >>
> >> I suspect the following is going on: The configuration is repeatedly
> >> updated and since delivery lags behind update, only the latest update
> >> state at the time of delivery is actually delivered.
> >>
> >> Consider for example 5 updates in succession. The first might be
> >> delivered, which delays the delivery thread. When the delivery thread
> >> takes the next update task from the queue, the most recent update (the
> >> fifth) is delivered. Updates 2-4 are not delivered.
> >>
> >> In the end it (theoretically) makes no difference. But I agree, that
> >> this is definitely not what is expected.
> >>
> >> So, I will have to refactor configuration delivery such that the actual
> >> update of each configuration is effectively delivered.
> >>
> >> Regards
> >> Felix
> >>
> >>
> >>>
> >>> Regards;
> >>> /pierre
> >>>
> >>>
> >>> On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger <
> fmeschbe@gmail.com
> >>> wrote:
> >>>
> >>>> Hi Pierre,
> >>>>
> >>>> Yes, I am afraid that you run into the FELIX-1545 issue ...
> >>>>
> >>>> Regards
> >>>> Felix
> >>>>
> >>>> On 24.04.2010 11:49, Pierre De Rop wrote:
> >>>>> Hello everyone, and Felix;
> >>>>>
> >>>>> I am using ConfigAdmin 1.2.4, and I have written a test case which is
> >>>> using
> >>>>> a ManagedServiceFactory, and consists in updating a Factory
> >> Configuration
> >>>>> object.
> >>>>> Something like:
> >>>>>
> >>>>> Configuration cf =
> configAdmin.createFactoryConfiguration(m_factoryPid,
> >>>>> null);
> >>>>> cf.update(new Properties() {{ put("foo", "bar"); }});
> >>>>>
> >>>>> And then, a little bit later, I update again the cf object, like
> this:
> >>>>>
> >>>>> cf.update(new Properties() {{ put("foo", "bar2"); }});
> >>>>>
> >>>>> So, most of the time, this test works fine. However, some times, the
> >> last
> >>>>> update seems to be missed, and I see the following CM logs:
> >>>>>
> >>>>> [LogService/4] Scheduling task Update:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Running task Update:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Configuration
> >>>>> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
> >>>> updated,
> >>>>> nothing to be done anymore.
> >>>>> [LogService/4] Scheduling task Fire ConfigurationEvent:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>> [LogService/4] Running task Fire ConfigurationEvent:
> >>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>>>
> >>>>> So, I have checked if some pending issues were addressing this
> eventual
> >>>>> problem, and I came across the issue FELIX-1545.
> >>>>> So, my question is the following:
> >>>>>
> >>>>> is my problem related to the FELIX-1545 issue ? if not, then should I
> >>>> open a
> >>>>> Jira issue ?
> >>>>>
> >>>>> thanks;
> >>>>> /pierre
> >>>>>
> >>>>
> >>>
> >>
> >
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Sorry for the long delay (caused by multiple distractions).
I have finally committed your testcase for FELIX-1545 and implemented a
fix for the problem. It turned out, that the fix was quite easy: instead
of setting the last updated field to the current value of the last
modified field it is now set to the value of the last modified field at
the time the update was scheduled.
As a consequence the configuration updates are not missed any longer.
After fixing a number of other bugs, too, I have now deployed a SNAPSHOT
(1.2.7-20100825.182233-1) which you might want to test.
I plan to cut a release candidate in a few days.
Thanks and Regards
Felix
On 27.04.2010 20:05, Pierre De Rop wrote:
> Hello Felix,
>
> Thanks for your explanation.
> After more investigations, I can now describe more specifically the issue I
> am facing, and in my use case, it sounds like the most recent update (the
> fifth in your previous example) is lost.
>
> It's not easy to explain, but here is what I am observing:
>
> 1) I have written to a junit test for dependency manager, which verifies
> some stuff regarding dependency manager and config admin.
>
> 2) In this junit test, I first create a factory configuration, which
> delivers an initial update to one given ManagedServiceFactory instance.
>
> 3) Now, in the "updated" method of my ManagedserviceFactory, I notify
> another thread "T" in order to inform that the update has taken place
> properly.
> So far so good.
>
> 4) At that point in time, the ConfigurationManager.java class (in CM) has
> returned from my ManagedServiceFactory.updated() method invocation, and is
> about to set the configuration last updated time (in
> ConfigurationManager.java, line 1531). This method will actually set the
> last update time to the most recent last modification time (If my
> understanding is correct).
>
> 5) But concurrently, the other thread "T" which has been notified from my
> ManagedServiceFactory.updated() method is UPDATING the configuration ... so
> the configuration last modification time is incremented.
>
> 6) Finally, the ConfigurationManager, line 1531, invokes the
> config.setLastUpdatedTime(), which actually uses the last modification time
> that has just been set in step 5) by the thread "T".
>
> 7) and when the update instigated from the thread "T" is about to be
> processed by the UpdateThread (in CM), then the following test succeeds and
> the update made by "T" is ignored:
>
> if ( lastModificationTime <= config.getLastUpdatedTime() )
> {
> log( LogService.LOG_DEBUG, "Configuration " +
> config.getPid() + " at modification #"
> + config.getLastModificationTime() + " has already
> been updated to update #"
> + config.getLastUpdatedTime() + ", nothing to be
> done anymore.", null );
> return;
> }
>
>
> So, here, it seems that we have lost the most recent update (made from
> thread "T").
> Am I correct with this explanation ?
>
> Now, I just read your last comment in issue 1545, where you propose to add a
> third sequence number.
> Would that third sequence number resolve my issue ?
> I am not sure whether I understand the purpose of this third counter you
> propose, can you please explain it ?
>
>
> thanks;
> /pierre
>
>
> On Mon, Apr 26, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi,
>>
>> On 25.04.2010 22:57, Pierre De Rop wrote:
>>> Then I have a junit test which reproduces the problem.
>>> Would you like me to attach it to the FELIX-1545 issue ?
>>
>> This is very helpful. Thanks.
>>
>> I suspect the following is going on: The configuration is repeatedly
>> updated and since delivery lags behind update, only the latest update
>> state at the time of delivery is actually delivered.
>>
>> Consider for example 5 updates in succession. The first might be
>> delivered, which delays the delivery thread. When the delivery thread
>> takes the next update task from the queue, the most recent update (the
>> fifth) is delivered. Updates 2-4 are not delivered.
>>
>> In the end it (theoretically) makes no difference. But I agree, that
>> this is definitely not what is expected.
>>
>> So, I will have to refactor configuration delivery such that the actual
>> update of each configuration is effectively delivered.
>>
>> Regards
>> Felix
>>
>>
>>>
>>> Regards;
>>> /pierre
>>>
>>>
>>> On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger <fmeschbe@gmail.com
>>> wrote:
>>>
>>>> Hi Pierre,
>>>>
>>>> Yes, I am afraid that you run into the FELIX-1545 issue ...
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>> On 24.04.2010 11:49, Pierre De Rop wrote:
>>>>> Hello everyone, and Felix;
>>>>>
>>>>> I am using ConfigAdmin 1.2.4, and I have written a test case which is
>>>> using
>>>>> a ManagedServiceFactory, and consists in updating a Factory
>> Configuration
>>>>> object.
>>>>> Something like:
>>>>>
>>>>> Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
>>>>> null);
>>>>> cf.update(new Properties() {{ put("foo", "bar"); }});
>>>>>
>>>>> And then, a little bit later, I update again the cf object, like this:
>>>>>
>>>>> cf.update(new Properties() {{ put("foo", "bar2"); }});
>>>>>
>>>>> So, most of the time, this test works fine. However, some times, the
>> last
>>>>> update seems to be missed, and I see the following CM logs:
>>>>>
>>>>> [LogService/4] Scheduling task Update:
>>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>>>> [LogService/4] Running task Update:
>>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>>>> [LogService/4] Configuration
>>>>> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
>>>> updated,
>>>>> nothing to be done anymore.
>>>>> [LogService/4] Scheduling task Fire ConfigurationEvent:
>>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>>>> [LogService/4] Running task Fire ConfigurationEvent:
>>>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>>>>
>>>>> So, I have checked if some pending issues were addressing this eventual
>>>>> problem, and I came across the issue FELIX-1545.
>>>>> So, my question is the following:
>>>>>
>>>>> is my problem related to the FELIX-1545 issue ? if not, then should I
>>>> open a
>>>>> Jira issue ?
>>>>>
>>>>> thanks;
>>>>> /pierre
>>>>>
>>>>
>>>
>>
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Pierre De Rop <pi...@gmail.com>.
Hello Felix,
Thanks for your explanation.
After more investigations, I can now describe more specifically the issue I
am facing, and in my use case, it sounds like the most recent update (the
fifth in your previous example) is lost.
It's not easy to explain, but here is what I am observing:
1) I have written to a junit test for dependency manager, which verifies
some stuff regarding dependency manager and config admin.
2) In this junit test, I first create a factory configuration, which
delivers an initial update to one given ManagedServiceFactory instance.
3) Now, in the "updated" method of my ManagedserviceFactory, I notify
another thread "T" in order to inform that the update has taken place
properly.
So far so good.
4) At that point in time, the ConfigurationManager.java class (in CM) has
returned from my ManagedServiceFactory.updated() method invocation, and is
about to set the configuration last updated time (in
ConfigurationManager.java, line 1531). This method will actually set the
last update time to the most recent last modification time (If my
understanding is correct).
5) But concurrently, the other thread "T" which has been notified from my
ManagedServiceFactory.updated() method is UPDATING the configuration ... so
the configuration last modification time is incremented.
6) Finally, the ConfigurationManager, line 1531, invokes the
config.setLastUpdatedTime(), which actually uses the last modification time
that has just been set in step 5) by the thread "T".
7) and when the update instigated from the thread "T" is about to be
processed by the UpdateThread (in CM), then the following test succeeds and
the update made by "T" is ignored:
if ( lastModificationTime <= config.getLastUpdatedTime() )
{
log( LogService.LOG_DEBUG, "Configuration " +
config.getPid() + " at modification #"
+ config.getLastModificationTime() + " has already
been updated to update #"
+ config.getLastUpdatedTime() + ", nothing to be
done anymore.", null );
return;
}
So, here, it seems that we have lost the most recent update (made from
thread "T").
Am I correct with this explanation ?
Now, I just read your last comment in issue 1545, where you propose to add a
third sequence number.
Would that third sequence number resolve my issue ?
I am not sure whether I understand the purpose of this third counter you
propose, can you please explain it ?
thanks;
/pierre
On Mon, Apr 26, 2010 at 9:44 AM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi,
>
> On 25.04.2010 22:57, Pierre De Rop wrote:
> > Then I have a junit test which reproduces the problem.
> > Would you like me to attach it to the FELIX-1545 issue ?
>
> This is very helpful. Thanks.
>
> I suspect the following is going on: The configuration is repeatedly
> updated and since delivery lags behind update, only the latest update
> state at the time of delivery is actually delivered.
>
> Consider for example 5 updates in succession. The first might be
> delivered, which delays the delivery thread. When the delivery thread
> takes the next update task from the queue, the most recent update (the
> fifth) is delivered. Updates 2-4 are not delivered.
>
> In the end it (theoretically) makes no difference. But I agree, that
> this is definitely not what is expected.
>
> So, I will have to refactor configuration delivery such that the actual
> update of each configuration is effectively delivered.
>
> Regards
> Felix
>
>
> >
> > Regards;
> > /pierre
> >
> >
> > On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger <fmeschbe@gmail.com
> >wrote:
> >
> >> Hi Pierre,
> >>
> >> Yes, I am afraid that you run into the FELIX-1545 issue ...
> >>
> >> Regards
> >> Felix
> >>
> >> On 24.04.2010 11:49, Pierre De Rop wrote:
> >>> Hello everyone, and Felix;
> >>>
> >>> I am using ConfigAdmin 1.2.4, and I have written a test case which is
> >> using
> >>> a ManagedServiceFactory, and consists in updating a Factory
> Configuration
> >>> object.
> >>> Something like:
> >>>
> >>> Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
> >>> null);
> >>> cf.update(new Properties() {{ put("foo", "bar"); }});
> >>>
> >>> And then, a little bit later, I update again the cf object, like this:
> >>>
> >>> cf.update(new Properties() {{ put("foo", "bar2"); }});
> >>>
> >>> So, most of the time, this test works fine. However, some times, the
> last
> >>> update seems to be missed, and I see the following CM logs:
> >>>
> >>> [LogService/4] Scheduling task Update:
> >>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>> [LogService/4] Running task Update:
> >>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>> [LogService/4] Configuration
> >>> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
> >> updated,
> >>> nothing to be done anymore.
> >>> [LogService/4] Scheduling task Fire ConfigurationEvent:
> >>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>> [LogService/4] Running task Fire ConfigurationEvent:
> >>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >>>
> >>> So, I have checked if some pending issues were addressing this eventual
> >>> problem, and I came across the issue FELIX-1545.
> >>> So, my question is the following:
> >>>
> >>> is my problem related to the FELIX-1545 issue ? if not, then should I
> >> open a
> >>> Jira issue ?
> >>>
> >>> thanks;
> >>> /pierre
> >>>
> >>
> >
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
On 25.04.2010 22:57, Pierre De Rop wrote:
> Then I have a junit test which reproduces the problem.
> Would you like me to attach it to the FELIX-1545 issue ?
This is very helpful. Thanks.
I suspect the following is going on: The configuration is repeatedly
updated and since delivery lags behind update, only the latest update
state at the time of delivery is actually delivered.
Consider for example 5 updates in succession. The first might be
delivered, which delays the delivery thread. When the delivery thread
takes the next update task from the queue, the most recent update (the
fifth) is delivered. Updates 2-4 are not delivered.
In the end it (theoretically) makes no difference. But I agree, that
this is definitely not what is expected.
So, I will have to refactor configuration delivery such that the actual
update of each configuration is effectively delivered.
Regards
Felix
>
> Regards;
> /pierre
>
>
> On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger <fm...@gmail.com>wrote:
>
>> Hi Pierre,
>>
>> Yes, I am afraid that you run into the FELIX-1545 issue ...
>>
>> Regards
>> Felix
>>
>> On 24.04.2010 11:49, Pierre De Rop wrote:
>>> Hello everyone, and Felix;
>>>
>>> I am using ConfigAdmin 1.2.4, and I have written a test case which is
>> using
>>> a ManagedServiceFactory, and consists in updating a Factory Configuration
>>> object.
>>> Something like:
>>>
>>> Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
>>> null);
>>> cf.update(new Properties() {{ put("foo", "bar"); }});
>>>
>>> And then, a little bit later, I update again the cf object, like this:
>>>
>>> cf.update(new Properties() {{ put("foo", "bar2"); }});
>>>
>>> So, most of the time, this test works fine. However, some times, the last
>>> update seems to be missed, and I see the following CM logs:
>>>
>>> [LogService/4] Scheduling task Update:
>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>> [LogService/4] Running task Update:
>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>> [LogService/4] Configuration
>>> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
>> updated,
>>> nothing to be done anymore.
>>> [LogService/4] Scheduling task Fire ConfigurationEvent:
>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>> [LogService/4] Running task Fire ConfigurationEvent:
>>> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>>>
>>> So, I have checked if some pending issues were addressing this eventual
>>> problem, and I came across the issue FELIX-1545.
>>> So, my question is the following:
>>>
>>> is my problem related to the FELIX-1545 issue ? if not, then should I
>> open a
>>> Jira issue ?
>>>
>>> thanks;
>>> /pierre
>>>
>>
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Pierre De Rop <pi...@gmail.com>.
Then I have a junit test which reproduces the problem.
Would you like me to attach it to the FELIX-1545 issue ?
Regards;
/pierre
On Sun, Apr 25, 2010 at 11:54 PM, Felix Meschberger <fm...@gmail.com>wrote:
> Hi Pierre,
>
> Yes, I am afraid that you run into the FELIX-1545 issue ...
>
> Regards
> Felix
>
> On 24.04.2010 11:49, Pierre De Rop wrote:
> > Hello everyone, and Felix;
> >
> > I am using ConfigAdmin 1.2.4, and I have written a test case which is
> using
> > a ManagedServiceFactory, and consists in updating a Factory Configuration
> > object.
> > Something like:
> >
> > Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
> > null);
> > cf.update(new Properties() {{ put("foo", "bar"); }});
> >
> > And then, a little bit later, I update again the cf object, like this:
> >
> > cf.update(new Properties() {{ put("foo", "bar2"); }});
> >
> > So, most of the time, this test works fine. However, some times, the last
> > update seems to be missed, and I see the following CM logs:
> >
> > [LogService/4] Scheduling task Update:
> > pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> > [LogService/4] Running task Update:
> > pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> > [LogService/4] Configuration
> > MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been
> updated,
> > nothing to be done anymore.
> > [LogService/4] Scheduling task Fire ConfigurationEvent:
> > pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> > [LogService/4] Running task Fire ConfigurationEvent:
> > pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> >
> > So, I have checked if some pending issues were addressing this eventual
> > problem, and I came across the issue FELIX-1545.
> > So, my question is the following:
> >
> > is my problem related to the FELIX-1545 issue ? if not, then should I
> open a
> > Jira issue ?
> >
> > thanks;
> > /pierre
> >
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Pierre,
Yes, I am afraid that you run into the FELIX-1545 issue ...
Regards
Felix
On 24.04.2010 11:49, Pierre De Rop wrote:
> Hello everyone, and Felix;
>
> I am using ConfigAdmin 1.2.4, and I have written a test case which is using
> a ManagedServiceFactory, and consists in updating a Factory Configuration
> object.
> Something like:
>
> Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
> null);
> cf.update(new Properties() {{ put("foo", "bar"); }});
>
> And then, a little bit later, I update again the cf object, like this:
>
> cf.update(new Properties() {{ put("foo", "bar2"); }});
>
> So, most of the time, this test works fine. However, some times, the last
> update seems to be missed, and I see the following CM logs:
>
> [LogService/4] Scheduling task Update:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Running task Update:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Configuration
> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been updated,
> nothing to be done anymore.
> [LogService/4] Scheduling task Fire ConfigurationEvent:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Running task Fire ConfigurationEvent:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>
> So, I have checked if some pending issues were addressing this eventual
> problem, and I came across the issue FELIX-1545.
> So, my question is the following:
>
> is my problem related to the FELIX-1545 issue ? if not, then should I open a
> Jira issue ?
>
> thanks;
> /pierre
>
Re: Issue with ConfigAdmin 1.2.4 ?
Posted by Pierre De Rop <pi...@gmail.com>.
just to tell that I also tested with the latest ConfigAdmin from trunk, and
it also seems that an update is missed:
[LogService/4] Scheduling task Update:
pid=MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8
[LogService/4]
UpdateConfiguration(MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8)
scheduled
[LogService/4] Updated configuration
MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8 to update #3
[LogService/4] Running task Update:
pid=MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8
[LogService/4] Configuration
MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8 at modification #3 has
already been updated to update #3, nothing to be done anymore.
[LogService/4] Scheduling task Fire ConfigurationEvent:
pid=MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8
[LogService/4] Running task Fire ConfigurationEvent:
pid=MyFactoryPid.1512b9c3-12f9-4671-8346-eec609d579f8
/pierre
On Sat, Apr 24, 2010 at 11:49 AM, Pierre De Rop <pi...@gmail.com>wrote:
> Hello everyone, and Felix;
>
> I am using ConfigAdmin 1.2.4, and I have written a test case which is using
> a ManagedServiceFactory, and consists in updating a Factory Configuration
> object.
> Something like:
>
> Configuration cf = configAdmin.createFactoryConfiguration(m_factoryPid,
> null);
> cf.update(new Properties() {{ put("foo", "bar"); }});
>
> And then, a little bit later, I update again the cf object, like this:
>
> cf.update(new Properties() {{ put("foo", "bar2"); }});
>
> So, most of the time, this test works fine. However, some times, the last
> update seems to be missed, and I see the following CM logs:
>
> [LogService/4] Scheduling task Update:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Running task Update:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Configuration
> MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087 has already been updated,
> nothing to be done anymore.
> [LogService/4] Scheduling task Fire ConfigurationEvent:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
> [LogService/4] Running task Fire ConfigurationEvent:
> pid=MyFactoryPid.c57f6e36-6e1a-4904-912f-26b021913087
>
> So, I have checked if some pending issues were addressing this eventual
> problem, and I came across the issue FELIX-1545.
> So, my question is the following:
>
> is my problem related to the FELIX-1545 issue ? if not, then should I open
> a Jira issue ?
>
> thanks;
> /pierre
>