[
https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13193043#comment-13193043
]
Felix Meschberger commented on FELIX-3317:
------------------------------------------
There are multiple approaches to this problem:
(1) Try to delay the destruction of the component due to the configuration
update if an "incomplete" satisified state is recognized
(2) Check state consistency after registering the service with the framework:
If the state after registration is still the same as before and the service
registration field has not been set (by another thread for example), the field
is set. Otherwise the field is left untouched and the service is unregistered
again (the backing object is most probably destroyed anyway).
The first solution must make sure to not create unsolvable deadlocks by for
example employing a timout in the delay instead of just waiting. Also an
indication of what "incomplete" means and is would be required.
The second solution really is a workaround since an invalid (or partially
invalid) service object is being distributed causing all sorts of log messages
(and may be trouble).
> Potential concurrency issue during Component Service registration
> -----------------------------------------------------------------
>
> Key: FELIX-3317
> URL: https://issues.apache.org/jira/browse/FELIX-3317
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
> Affects Versions: scr-1.6.0
> Reporter: Felix Meschberger
> Assignee: Felix Meschberger
> Fix For: scr-1.6.2
>
>
> In our Sling-based application we saw the following behavior: The Sling
> ResourceResolverFactory is a component being activated. Yet every now and
> then a field of that component seems to become null which is not expected for
> an activated ResourceResolverFactory component and thus causes a
> NullPointerException.
> Upon inspection I saw, that for the same Declarative Services component two
> Services have been registered where only one was actually expected.
> Turns out that consumers of the ResoureResovlerFactory where all bound to the
> same service. The component on the other hand has been cycled due to a
> configuration update. So one service is backed by a deactivated component
> (whose field has been reset to null already) and the other service is live.
> The problem is that the service backed by the deactivated method has not been
> unregistered and thus all consumers are hooked up to the deactivated instance
> causing all sorts of problems ...
> This is what most probably happens in the AbstractComponentManager:
> * T1 Unsatisfied.activate has set the state to Active already
> before calling registerService
> * T1 registerService is called but the service registration field
> field is not assigned yet
> during registerService ServiceListeners are called
> * T2 A Configuration update comes in and
> Satisfied(Active).deactivate is called
> * T2 calls unregisterComponentService; does nothing because the
> service registration field is not assigned
> * T2 destroys component
> * T1 assigns field from service registration
> As a result the deactivated object's service registration may be unregistered
> later when the component is cycled again and the second service registration
> will only be unregistered when the providing bundle is restarted.
--
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
