Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
configadmin-1.2.4
-
None
Description
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 !