[jira] [Created] (FELIX-4223) [DS] DependencyManager filter should be set up in enable, not activate, to avoid race conditions

["David Jencks (JIRA)" <ji...@apache.org>]

David Jencks created FELIX-4223:
-----------------------------------

             Summary: [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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira