felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Issue with ConfigAdmin 1.2.4 ?
Date Thu, 26 Aug 2010 07:21:06 GMT
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 <mailto: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 <mailto: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
>     >>>>>
>     >>>>
>     >>>
>     >>
>     >
> 
> 

Mime
View raw message