felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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 Thu, 24 Mar 2011 12:32:05 GMT

    [ https://issues.apache.org/jira/browse/FELIX-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010646#comment-13010646
] 

Felix Meschberger commented on FELIX-2888:
------------------------------------------

Well, the createFactoryConfiguration method creates just a transient configuration object
which is not persisted; in fact not even internally known to exist. So before informing "your
friends" in the second step you currently would have to call Configuration.update(Dictionary)
before informing "your friends".

In addition "your excited friend" taking a "peek" is probably calling getConfiguration this
will create a Configuration if not existing yet -- which is the case here because the factory
configuration does not exist yet. But then this now existing configuration is not a factory
configuration but a singleton configuration whose Configuration.getFactoryPid() method will
return null.

I think I can build this additional stability (kind of semi-caching the created factory configuration)
into Configuration Admin without much effort.


> 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