felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Jencks (JIRA)" <j...@apache.org>
Subject [jira] [Closed] (FELIX-4055) [DS] Component instance unset but remains in Active state
Date Tue, 15 Oct 2013 23:37:42 GMT

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

David Jencks closed FELIX-4055.

> [DS] Component instance unset but remains in Active state
> ---------------------------------------------------------
>                 Key: FELIX-4055
>                 URL: https://issues.apache.org/jira/browse/FELIX-4055
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>    Affects Versions: scr-1.8.0
>            Reporter: David Jencks
>            Assignee: David Jencks
>             Fix For: scr-1.8.0
> We observed something very odd with rev 1467353.  We have a delayed component that is
no longer used, so (I believe) the framework calls ungetService and we dispose of the implementation
object.  However it looks like the component remains in the active state and subsequent calls
to getService return null.
> Evidence from the logs:
> (using component): Deactivating dependency managers
> (peculiar component) getting deactivate: deactivate
> ...
> Unset and deconfigured implementation object for component *** in deleteComponent for
reason Unspecified
> ... 500 milliseconds later ...
> This thread collected dependencies
> getService won collecting dependencies, proceed to creating object. (returns null).
> AFAICT the ungetService goes through this code:
>         void ungetService( ImmediateComponentManager dcm )
>         {
>             dcm.deleteComponent( ComponentConstants.DEACTIVATION_REASON_UNSPECIFIED );
>             if ( dcm.enabled )
>             {
>                 dcm.changeState( Registered.getInstance() );
>             }
>         }
> which suggests that perhaps the enabled state is false.  This should have produced a
state change and in particular a service unregistration, and there is no code that would be
disabling any of the components.
> However we got into this state, there appears to be an over-reliance on states in getService
that is easy to fix and appears to be harmless, if there is no implementation object we can
just use Registered.getInstance() to create it rather than state().

This message was sent by Atlassian JIRA

View raw message