felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "jamie campbell (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-2888) if you create a factory configuration and anybody takes a peek before you've had a chance to update, your pudding is trapped forever
Date Sun, 20 Mar 2011 23:23:06 GMT
if you create a factory configuration and anybody takes a peek before you've had a chance to
update, your pudding is trapped forever
------------------------------------------------------------------------------------------------------------------------------------

                 Key: FELIX-2888
                 URL: https://issues.apache.org/jira/browse/FELIX-2888
             Project: Felix
          Issue Type: Bug
          Components: Configuration Admin
    Affects Versions:  configadmin-1.2.8
         Environment: Ubuntu 10.04
            Reporter: jamie campbell
            Priority: Minor


If you create a factory configuration and then one of your bundle comrades (or another internal
class) has a peek to see if there's anything ready yet, the original code that created the
factory configuration is locked out because the peeker triggers a cache of a NEW configuration.

Here's the sequence

1) 
Userside -> call createFactoryConfiguration and catch the return value so you can do an
update with it
felix side -> creates the configuration but doesn't cache it

2)
Userside -> let your friends know about the pid which they can peek at for future reference.
 One of your friends is excited and peeks immediately (or soon after being informed).
felix side -> since an update hasn't been done yet, it creates a new configuration and
puts it in cache

3)
Userside -> The code that called createFactoryConfiguration finishes its pondering and
is ready to call conf.update(props) .. it gets no exception from the void method and so carries
on with life.
felix side -> The cache already has something in it for this pid, so updates to the generated
conf no longer have any effect, so the caller of createFactoryConfiguration's assumptions
of update success are erroneous

4) 
Userside -> Someone does listConfigurations, and doesn't see this conf
felix side -> This is because the system still believes that the configuration has no properties

It's also useful to note that it is NOT a workaround to simply kludge things by doing a config
regrab immediately before doing the update(props) operation because the config generated and
cached by the peek call was NOT a factory configuration, because getConfiguration() had no
reason to believe it should autogenerate a factory config, so it autogenerates a normal one.

I think (but am not totally sure) that this may have been a regression from FELIX-612

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message