felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pierre De Rop (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (FELIX-4297) [DS] timing hole in opening a dependency manager
Date Tue, 29 Oct 2013 16:14:31 GMT

     [ https://issues.apache.org/jira/browse/FELIX-4297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Pierre De Rop updated FELIX-4297:
---------------------------------

    Attachment: stacktrace.log

While testing, I got two "timeount on latch" logs, following by some stacktraces.

For simplicity, I changed the current dumpThreads method in order to log in WARN, instead
of DEBUG, in order to reproduce the problem without having too much logs.

Also: should this dumpstack be logged in WARN instead of DEBUG ? 


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