[jira] Commented: (FELIX-1545) Configurations may still be delivered more than once (or not at all)

["Felix Meschberger (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FELIX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902435#action_12902435 ] 

Felix Meschberger commented on FELIX-1545:
------------------------------------------

Rev. 989094

Committed Pierre de Rop's test case (thanks alot for providing) slightly enhanced to not only ensure delivery of the configuration but also to ensure the correct configuration is actually delivered.

Modified the way the last update flag for configurations is set: Asynchronous configuration delivery is implemented as tasks, which are setup at the time of the configuration update (or service event processing). At this time the current configuration properties are extracted from the configuration as well as the last modification time of these properties. This kind of a timestamped snapshot of the configuration properties.

At the time of the configuration update (asynchronously as mandated by the spec), last modification time is compared to the actual last update time field of the configuration object. If the last update time is higher than the last modification time of the update task, nothing is done. Otherwise the update takes place and the last update time field is now set to the last modification time of the properties just updated.

Previously the last update time field was set to the last modification time value at the time of configuration update. This is wrong, because it may cause configurations to get lost.

All our integration tests (including the new one) now pass. But there are 3 OSGi CT test failures I have to further investigate before resolving this issue fixed.

> 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.8
>
>         Attachments: cm-stress-test.tgz
>
>
> 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.