[
https://issues.apache.org/jira/browse/FELIX-3721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger closed FELIX-3721.
------------------------------------
> 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
> Affects Versions: configadmin-1.6.0
> Environment: Java 6 on Linux platforms
> Reporter: Felix Meschberger
> Assignee: 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
