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] [Commented] (FELIX-4297) [DS] timing hole in opening a dependency manager
Date Tue, 29 Oct 2013 18:48:26 GMT

    [ 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)

Mime
View raw message