felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] Updated: (FELIX-1545) Configurations may still be delivered more than once (or not at all)
Date Mon, 26 Apr 2010 07:07:36 GMT

     [ https://issues.apache.org/jira/browse/FELIX-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Pierre De Rop updated FELIX-1545:
---------------------------------

    Attachment: cm-stress-test.tgz

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


Mime
View raw message