[
https://issues.apache.org/jira/browse/FELIX-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407042#comment-13407042
]
Felix Meschberger commented on FELIX-3577:
------------------------------------------
The last change introduced a race condition between service registration
(particularly ManagedServiceFactory) and concurrent configuration update
(example uses ManagedServiceFactory):
T2: creates/updates configuration
- create factory config
- update factory config
- store config
- update internal factory map
- T2 preempted
T1: register service
- ServiceTracker calls addingService
- gets the service PIDs
- for each PID:
- find config
- check config (ignoring new configs)
- schedule update
- T1 preempted
T2: picks up again to continue persisting the configuration
- internally set config non-new
- schedule update
The configuration update (on the ConfigurationUpdateThread) in T2 may not find
a registered service because addingService in T1 has not completed yet and thus
the service is not yet officially known by the ServiceTracker, which in turn is
used by the ConfigurationUpdate to look for targets to configure.
The configuration update due to T1 fails because the
ManagedServiceFactoryUpdate constructor may find a configuration but ignores it
because it is still new (Configuration.update(Dictionary) in T2 has not yet
completed its work). On the ConfigurationUpdateThread the
ManagedServiceFactoryUpdate does nothing because there is no valid
configuration to provide.
> Refactor helpers and service trackers
> -------------------------------------
>
> Key: FELIX-3577
> URL: https://issues.apache.org/jira/browse/FELIX-3577
> Project: Felix
> Issue Type: Improvement
> Components: Configuration Admin
> Affects Versions: configadmin-1.4.0
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: configadmin-1.6.0
>
>
> The ConfigurationManager class currently hosts quite a number of inner
> classes to help with its tasks. A few of these classes have overlapping
> functionality which makes it hard to easily implement targeted PIDs these
> functionalities should be better aligned:
> * ManagedService[Factory]Tracker don't really get the services but maintain
> a map of PIDs and assigned
> configurations (most importantly the targeted PID and configuration
> modification counter)
> * ManagedService[Factory] callbacks are also executed by the tracker classes
> * The ManagedService[Factory]Helper classes are renamed to
> [Factory]ConfigurationHelper since
> they are helpers to convey configuration to ManagedService[Factory]
> services through the respective
> trackers.
> * The ServiceHolder class is replaced by the ConfigurationMap class managed
> by the trackers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
