felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Felix Meschberger (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (FELIX-3317) Potential concurrency issue during Component Service registration
Date Wed, 25 Jan 2012 13:18:40 GMT
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
                    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