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] [Resolved] (FELIX-4223) [DS] DependencyManager filter should be set up in enable, not activate, to avoid race conditions
Date Tue, 15 Oct 2013 23:45:43 GMT

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

David Jencks resolved FELIX-4223.
---------------------------------

    Resolution: Fixed

> [DS] DependencyManager filter should be set up in enable, not activate, to avoid race
conditions
> ------------------------------------------------------------------------------------------------
>
>                 Key: FELIX-4223
>                 URL: https://issues.apache.org/jira/browse/FELIX-4223
>             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
>
>
> Currently target filters on DependencyManager are set during activation.  This can cause
a race condition between a thread on which a service dependency is registered and a thread
requesting a service.  A simple solution to this is to set up the filters during enable (and
of course modify them on configuration updates).  This makes sense to me since activation
can never by itself change the target filter.
> The symptoms we saw of the race condition were
> Caused by: java.lang.NullPointerException
> 	at org.apache.felix.scr.impl.manager.DependencyManager.open(DependencyManager.java:1454)
> 	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createImplementationObject(ImmediateComponentManager.java:266)
> 	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.createComponent(ImmediateComponentManager.java:123)
> 	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.getService(ImmediateComponentManager.java:800)
> 	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.getServiceInternal(ImmediateComponentManager.java:767)
> 	at org.apache.felix.scr.impl.manager.ImmediateComponentManager.getService(ImmediateComponentManager.java:706)
> 	at org.eclipse.osgi.internal.serviceregistry.ServiceUse$1.run(ServiceUse.java:141)
> In this code base the NPE is from trackerRef.get() == null.
> I don't entirely understand how the NPE occurs, it appears to require the jvm to reorder
some instructions that don't look to me reorderable, but there is obviously a problem with
concurrent access to setTarget if a second thread calls it while the first thread is in this
block:
>         customizer.setTracker( tracker );
>         registered = true;
> //first thread parked here
>         tracker.open( m_componentManager.getTrackingCount() );
>         customizer.setTrackerOpened();
> the second thread will use the registered flag to not actually open the tracker, there
is a code block earlier that exits if registered == true and there is no filter change.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message