[
https://issues.apache.org/jira/browse/FELIX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13808295#comment-13808295
]
David Jencks commented on FELIX-4297:
-------------------------------------
Added one possible fix for the latch timeout in rev 1536844
I'm slightly reluctant to make all dumpThreads log at WARN since it's also
called from the circular dependency detection, which does not necessarily
indicate an error. Rather than making the log level configurable I'm tempted
to leave it as is and ask people who find bugs to turn up the log level.
(hopefully we'll fix all these bugs soon :-)
> [DS] timing hole in opening a dependency manager
> ------------------------------------------------
>
> Key: FELIX-4297
> URL: https://issues.apache.org/jira/browse/FELIX-4297
> 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
>
> Attachments: stacktrace.log
>
>
> Pierre de Rop saw this running the integration tests:
> test_concurrent_injection_with_bundleContext(org.apache.felix.scr.integration.Felix3680_2Test)
> Time elapsed: 36.597 sec <<< ERROR!
> java.lang.NullPointerException
> at
> org.apache.felix.scr.impl.manager.DependencyManager.invokeUnbindMethod(DependencyManager.java:1710)
> at
> org.apache.felix.scr.impl.manager.SingleComponentManager.invokeUnbindMethod(SingleComponentManager.java:387)
> at
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:355)
> at
> org.apache.felix.scr.impl.manager.DependencyManager$MultipleDynamicCustomizer.removedService(DependencyManager.java:290)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1503)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.customizerRemoved(ServiceTracker.java:1398)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$AbstractTracked.untrack(ServiceTracker.java:1258)
> at
> org.apache.felix.scr.impl.manager.ServiceTracker$Tracked.serviceChanged(ServiceTracker.java:1437)
> at
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:932)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:793)
> at
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:543)
> at org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:4260)
> at org.apache.felix.framework.Felix.access$000(Felix.java:74)
> at org.apache.felix.framework.Felix$1.serviceChanged(Felix.java:390)
> at
> org.apache.felix.framework.ServiceRegistry.unregisterService(ServiceRegistry.java:148)
> at
> org.apache.felix.framework.ServiceRegistrationImpl.unregister(ServiceRegistrationImpl.java:127)
> at
> org.apache.felix.scr.integration.components.felix3680_2.Main$RegistrationHelper$2.run(Main.java:136)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
> The problem is that a service is being removed between the time the component
> instance is being created and the time the dependency manager is opened, and
> there is no open latch yet. I see that the EdgeInfos are never reused, so
> the fix appears to be to:
> 1. set up all the edgeInfos in the ComponentContextImpl constructor, avoiding
> a race (not observed AFAIK) in getEdgeInfo
> 2. make the open latch and close latch in EdgeInfo final
> 3. in DependencyManager.invokeUnbind and invokeUpdated make sure open is
> complete before checking outOfRange.
> 4. distinguish between out of range before and after.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
