[
https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Felix Meschberger updated FELIX-3317:
-------------------------------------
Summary: Concurrency issue during Component Service registration (was:
Potential concurrency issue during Component Service registration)
> 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