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
> <[email protected] <mailto:[email protected]>>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
> <[email protected] <mailto:[email protected]>
> >>> 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
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
