Felix Meschberger created FELIX-3721:
----------------------------------------
Summary: Configuration not always provided upon initial service
registration
Key: FELIX-3721
URL: https://issues.apache.org/jira/browse/FELIX-3721
Project: Felix
Issue Type: Bug
Components: Configuration Admin, Specification compliance
Environment: Java 6 on Linux platforms
Reporter: Felix Meschberger
Priority: Blocker
Fix For: configadmin-1.6.0
With the changes to implement Targeted PIDs and refactoring of the service
trackers for FELIX-3577 and FELIX-3481 a race condition has been introduced
which may cause ManagedService and ManagedServiceFactory services to not be
called back on initial registration.
This has been exhibited by test build of the yet unpublished OSGi CT for
Configuration Admin, for example:
(1) ManagedService PID 1 registered
(2) ManagedService PID 2 registered
(3) ManagedService PID 2 called back
The problem is, that before the call back to ManagedService PID 2, the call
back to ManagedService PID 1 is expected.
Turns out that this race condition takes place, which may primarily be
reproduced on Linux platforms, probably due to different threading
implementations on the platform:
T1: register service
T1: call ServiceTracker.addingService
T1: schedule service update task
T2: run update task
T2: terminate update task without calling the service
T1: return from ServiceTracker.addingService returning ConfigurationMap
This is expected since the service update task in T2 expects the
ConfigurationMap stored in the ServiceTracker. But this is not the case yet
because the ServiceTracker.addingService method has not yet returned it for it
to be stored in the ServiceTracker. Therefore T2 is not able to call back the
service and thus the update call never takes place.
The fix is either to delay the task execution in T2 or to prepare the
ConfigurationMap in T1 and hand it over to the task to be executed in T2. The
first solution is suboptimal because we cannot find a timing value which (a)
does not delay too much bug (b) still makes sure the ConfigurationMap will
ultimately be available.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
