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-5318) SCR causes startup to wait when bundle uninstall itself in activator
Date Wed, 03 Aug 2016 05:41:20 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15405348#comment-15405348

David Jencks commented on FELIX-5318:

In r1755018 and r1755019 I think I solved the problem in a different way using a lock rather
than avoiding the countdown latch.  Could you see if it fixes the problem in your scenario?
 I haven't had time to write a test.

> SCR causes startup to wait when bundle uninstall itself in activator
> --------------------------------------------------------------------
>                 Key: FELIX-5318
>                 URL: https://issues.apache.org/jira/browse/FELIX-5318
>             Project: Felix
>          Issue Type: Bug
>          Components: Declarative Services (SCR)
>            Reporter: Chetan Mehrotra
>            Assignee: David Jencks
>            Priority: Minor
>             Fix For: scr-2.0.6
>         Attachments: FELIX-5318-v1.patch
> If a bundle which does not have any service component configured uninstall itself upon
activation then SCR waits for latch to timeout in {{Activator$ScrExtension.destroy}}
> The threaddump indicate that FelixStartLevel thread is waiting for latch to timeout
> {noformat}
> "FelixStartLevel" daemon prio=10 tid=0x00007f4df45c5000 nid=0x65e6 waiting on condition
>    java.lang.Thread.State: TIMED_WAITING (parking)
> 	at sun.misc.Unsafe.park(Native Method)
> 	- parking to wait for  <0x0000000783400420> (a java.util.concurrent.CountDownLatch$Sync)
> 	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
> 	at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
> 	at org.apache.felix.scr.impl.Activator$ScrExtension.destroy(Activator.java:268)
> 	at org.apache.felix.utils.extender.AbstractExtender$2.run(AbstractExtender.java:290)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> 	at org.apache.felix.utils.extender.AbstractExtender.destroyExtension(AbstractExtender.java:312)
> 	at org.apache.felix.utils.extender.AbstractExtender.bundleChanged(AbstractExtender.java:186)
> 	at org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
> 	at org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
> 	at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
> 	at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
> 	at org.apache.felix.framework.Felix.stopBundle(Felix.java:2600)
> 	at org.apache.felix.framework.Felix.uninstallBundle(Felix.java:2712)
> 	at org.apache.felix.framework.BundleImpl.uninstall(BundleImpl.java:1055)
> 	at com.foo.bar.Initializer.activate(Initializer.java:71)
> {noformat}
> This happens at [1] most likely because Framework has not invoked started yet so latch
is not changed. As a fix destroy method should check if the bundle being stopped has any service
component. If not it should then not wait on the latch
> [1] https://github.com/apache/felix/blob/trunk/scr/src/main/java/org/apache/felix/scr/impl/Activator.java#L280

This message was sent by Atlassian JIRA

View raw message