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 <[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]
>>> 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
>>>>>
>>>>
>>>
>>
>
