[
https://issues.apache.org/jira/browse/FELIX-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989094#comment-12989094
]
Felix Meschberger commented on FELIX-2813:
------------------------------------------
Thanks for reporting the bug.
First of all declaring the configurationAdminRegistration volatile should help
your concerns with the getServiceReference() method; particularly with respect
to logging. On the other hand for the getServiceReference() method itself, this
is irrelelvant.
Second the other issue is in fact not properly handled but easily fixed:
Instead of immediately starting the worker threads for the UpdateQueue
instances, we delay the start until after the ConfigurationAdmin service has
been fully registered. This allows for events to be queued during the service
registration process (by ServiceListeners) and to actually process them after
completion of the registration.
This problem has a symmetry in the ConfigurationManager.stop(BundleContext)
method: Here the queues should be stopped before unregistering the
ConfigurationAdmin service to not get an NPE if a ServiceListener is
updating/deleting configuration in the serviceStopped method.
> NPE in UpdateThread when updating a configuration right after
> ConfigurationAdmin service starts
> -----------------------------------------------------------------------------------------------
>
> Key: FELIX-2813
> URL: https://issues.apache.org/jira/browse/FELIX-2813
> Project: Felix
> Issue Type: Bug
> Components: Configuration Admin
> Reporter: Marcel Offermans
>
> When you:
> 1) register as a configuration listener
> 2) wait for the ConfigurationAdmin service to start
> 3) upon start, immediately create a new configuration and update its
> properties
> You (sometimes) get a NPE in the UpdateThread because there is a race
> condition in the codebase:
> a) ConfigurationManager.java:1818 will invoke getServiceReference() which
> uses the service registration to get to the reference
> b) ConfigurationManager.java:242 registers the service and assigns the
> registration to 'configurationAdminRegistration'
> First of all, the call to registerService in line 242 will already trigger
> service listeners and trackers to invoke callbacks before this call returns,
> so 'configurationAdminRegistration' will still be null. Furthermore, there is
> no synchronization, the member is not volatile, so we need to make sure this
> value is really written before any configuration events are created under a)
> (now the thread doing that is started way before the service is registered).
> I will commit a test that shows the exception, but since it happens in a
> thread I cannot "catch" it won't show up as a failed test.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
