[
https://issues.apache.org/jira/browse/FELIX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre De Rop updated FELIX-4297:
---------------------------------
Attachment: stacktrace2.log
Ok, in fact, I did not know that it was intentional to log this dump stack in
debug , and I have no problem with this. Now, I know it :-)
I have tested the fix in rv 1536844, but I'm still having the two "timeout on
latch" logs , including the stacktraces in debug.
I have attached stacktrace2.log to this issue.
In this log, I also joined every DS debug logs, in case it may help.
let me know if you need more informations.
> [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: stacktrace2.log, 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)
