You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (JIRA)" <ji...@apache.org> on 2009/08/31 15:44:32 UTC
[jira] Commented: (FELIX-1545) Configurations may still be
delivered more than once (or not at all)
[ https://issues.apache.org/jira/browse/FELIX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749495#action_12749495 ]
Felix Meschberger commented on FELIX-1545:
------------------------------------------
Committed test cases exhibiting the problems in this issue in Rev. 809592.
> Configurations may still be delivered more than once (or not at all)
> --------------------------------------------------------------------
>
> Key: FELIX-1545
> URL: https://issues.apache.org/jira/browse/FELIX-1545
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
> Affects Versions: configadmin-1.2.4
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: configadmin-1.2.6
>
>
> Even after "fixing" FELIX-1146 and FELIX-1542 configurations may be delivered more than once. Under lab conditions it can even be observed, that configuration is not delivered at all.
> After digging into this issue a bit further (and writing test cases), it looks like we have three issues:
> (1) The granularity of System.currentTimeMillis() to feed the last modification time and last update time fields is to coarse causing false positives when testing whether configuration should be supplied or not
> (2) In contrast to service update due to Configuration.update(Dictionary), the updates cause by ManagedService[Factory] service registration do not observe the last update time field and thus may cause duplicate delivery
> T1: update configuration, schedule update task
> T2: register ManagedService, schedule update task
> T3: run update task from T1 --> ManagedService is registered and updated
> T3: run update task from T1 --> ManagedService is updated because last update time flag is ignored
> This last update call should not take place and must be guarded
> (3) After a service update the ManagedService update tasks (handling update after ManagedService registration) always sets the last update time flag, regardless of whether configuration properties exist or not.
> T1: create (empty) configuration
> T2: register ManagedService, schedule update task
> T1: update configuration, schedule update task
> T3: runs update task from T2, updates ManagedService with null (no proeprties) and updates last update time
> (last update time is now higher than last modification time even though no properties have been supplied)
> T3: runs update task from T1, but does *not* update ManagedService because last update > last modification
> Please note, that the third issue is actually much worse since it prevents the ManagedService from getting configuration at all !
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (FELIX-1545) Configurations may still be delivered
more than once (or not at all)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
Felix Meschberger (JIRA) schrieb:
> [ https://issues.apache.org/jira/browse/FELIX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12749495#action_12749495 ]
>
> Felix Meschberger commented on FELIX-1545:
> ------------------------------------------
>
> Committed test cases exhibiting the problems in this issue in Rev. 809592.
FYI: These test cases are expected to cause the bamboo build to fail.
This is an expected (and actaully I hope it happens ...) situation which
will go away as soon as I committ the code fixes.
Regards
Felix
>
>> Configurations may still be delivered more than once (or not at all)
>> --------------------------------------------------------------------
>>
>> Key: FELIX-1545
>> URL: https://issues.apache.org/jira/browse/FELIX-1545
>> Project: Felix
>> Issue Type: Bug
>> Components: Configuration Admin
>> Affects Versions: configadmin-1.2.4
>> Reporter: Felix Meschberger
>> Assignee: Felix Meschberger
>> Fix For: configadmin-1.2.6
>>
>>
>> Even after "fixing" FELIX-1146 and FELIX-1542 configurations may be delivered more than once. Under lab conditions it can even be observed, that configuration is not delivered at all.
>> After digging into this issue a bit further (and writing test cases), it looks like we have three issues:
>> (1) The granularity of System.currentTimeMillis() to feed the last modification time and last update time fields is to coarse causing false positives when testing whether configuration should be supplied or not
>> (2) In contrast to service update due to Configuration.update(Dictionary), the updates cause by ManagedService[Factory] service registration do not observe the last update time field and thus may cause duplicate delivery
>> T1: update configuration, schedule update task
>> T2: register ManagedService, schedule update task
>> T3: run update task from T1 --> ManagedService is registered and updated
>> T3: run update task from T1 --> ManagedService is updated because last update time flag is ignored
>> This last update call should not take place and must be guarded
>> (3) After a service update the ManagedService update tasks (handling update after ManagedService registration) always sets the last update time flag, regardless of whether configuration properties exist or not.
>> T1: create (empty) configuration
>> T2: register ManagedService, schedule update task
>> T1: update configuration, schedule update task
>> T3: runs update task from T2, updates ManagedService with null (no proeprties) and updates last update time
>> (last update time is now higher than last modification time even though no properties have been supplied)
>> T3: runs update task from T1, but does *not* update ManagedService because last update > last modification
>> Please note, that the third issue is actually much worse since it prevents the ManagedService from getting configuration at all !
>