[
https://issues.apache.org/jira/browse/FELIX-4223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks closed FELIX-4223.
-------------------------------
> [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)
