felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (Resolved) (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (FELIX-3317) Concurrency issue during Component Service registration
Date Thu, 26 Jan 2012 14:48:40 GMT

     [ 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
>          *  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


View raw message