felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre De Rop <pierre.de...@gmail.com>
Subject Re: Issue with ConfigAdmin 1.2.4 ?
Date Wed, 25 Aug 2010 20:21:30 GMT
On Wed, Aug 25, 2010 at 8:40 PM, Felix Meschberger <fmeschbe@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
> >>>>>
> >>>>
> >>>
> >>
> >
>

Mime
  • Unnamed multipart/related (inline, None, 0 bytes)
View raw message