You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Felix Meschberger (Resolved) (JIRA)" <ji...@apache.org> on 2012/01/26 15:48:40 UTC

[jira] [Resolved] (FELIX-3317) Concurrency issue during Component Service registration

     [ https://issues.apache.org/jira/browse/FELIX-3317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger resolved FELIX-3317.
--------------------------------------

    Resolution: Fixed

I think this works now. Will create follow-up issues if problems surface.
                
> 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