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] Resolved: (FELIX-1477) ConfigAdmin implementation is not thread-safe
Date Fri, 14 Aug 2009 19:52:14 GMT

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

Felix Meschberger resolved FELIX-1477.
--------------------------------------

       Resolution: Fixed
    Fix Version/s: configadmin-1.0.12
         Assignee: Felix Meschberger

Thanks for providing the patch.

I have applied it (slightly modified for formatting) in Rev. 804344.

Please close this issue, if it now works as expected for you. Thanks.

> ConfigAdmin implementation is not thread-safe
> ---------------------------------------------
>
>                 Key: FELIX-1477
>                 URL: https://issues.apache.org/jira/browse/FELIX-1477
>             Project: Felix
>          Issue Type: Bug
>          Components: Configuration Admin
>    Affects Versions: configadmin-1.0.10
>            Reporter: Andy Wilkinson
>            Assignee: Felix Meschberger
>             Fix For: configadmin-1.0.12
>
>         Attachments: thread-safety.patch
>
>
> I've been doing some work with ConfigAdmin in a multi-threaded environment and have come
across a number of issues caused by thread safety problems. The symptoms are typically either
an IllegalStateException from ConfiguationAdapter.checkDeleted when, in fact, the Configuration
has not been deleted, or a NPE, where PersistenceManager is checked once for being non-null,
and the used again without re-checking for it having been nulled out, e.g. due to concurrent
invocations of delete and update.
> I tracked down a common cause of the IllegalStateException from checkDeleted to FilePersistenceManager's
exists method. If exists is called on one thread while store (for an update) is being run
on another, the rename can cause exists to incorrectly return false. synchronizing on this
in exists appears to resolve this problem.
> I've produced a patch that goes someway to improve the thread-safety, although I does
not make the implementation completely thread-safe. Without the patch in place I was seeing
a failure about one run in three. Since applying the patch I have yet to see a failure after
more than 100 runs.

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