[
https://issues.apache.org/jira/browse/FELIX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12861365#action_12861365
]
Felix Meschberger commented on FELIX-1545:
------------------------------------------
The configuration manager currently maintains two counters for configuration
updates: one for actual calls to the Configuration.update(Dictionary) method
(the last modification counter) and one for the actual delivery of the
configuration to the ManagerService[Factory] (the last update counter).
When a configuration is now provided to a ManagedService[Factory] the last
update counter is set to the value of the last modification counter. This may
cause multiple configuration updates to be missed if the rate of calls to the
Configurtion.update(Dictionary) method is higher than the rate of actual
delivery of configuraiton to ManagedService[Factory] services.
As a solution we might want to introduce another counter, a service
registration counter.
* the last modification counter is maintained according to the
Configuration.update(Dictionary) method
* the last update counter is set by the UpdateTask and checked by the
ManagedService[Factory]Update task
* the service registration counter is set by the
ManagedService[Factory]Update task and checked by the UpdateTask
This should allow for consecutive configuration updates to all be delivered to
the ManagedSerivce[Factory] services but prevent provisiong of the same
configuration to the same service multiple times upon new service registration.
> 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.
