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 ! >
