[
https://issues.apache.org/jira/browse/FELIX-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger resolved FELIX-2813.
--------------------------------------
Resolution: Fixed
Fix Version/s: configadmin-1.2.10
Assignee: Felix Meschberger
Committed a fix in Rev. 1066033.
Besides making the service registration field volatile (as proposed) the
background threads are started after registering the service (though jobs may
be enqueued during the service registration) and are stopped before the service
is unregistered.
> 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
> Assignee: Felix Meschberger
> Fix For: configadmin-1.2.10
>
>
> 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
