[
https://issues.apache.org/jira/browse/FELIX-4055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks resolved FELIX-4055.
---------------------------------
Resolution: Fixed
> [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
(v6.1#6144)
