You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by "John Ross (JIRA)" <ji...@apache.org> on 2012/12/07 14:37:21 UTC
[jira] [Comment Edited] (ARIES-982) Deadlock between Subsystems
EventHook and Activator
[ https://issues.apache.org/jira/browse/ARIES-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526389#comment-13526389 ]
John Ross edited comment on ARIES-982 at 12/7/12 1:36 PM:
----------------------------------------------------------
The crux of the issue is that something is reacting to the root subsystem service registration (i.e. the initialization of subsystems) by spawning a new thread that installs a bundle. That something then parks on a future waiting for the other thread to finish before continuing. The subsystem bundle event hook reacts to the bundle installation to ensure it gets assigned to the proper subsystem (i.e. isolation scope). However, the bundle event hook cannot proceed because the subsystems initialization has not completed. Even though there are two different threads involved, the deadlock still occurs because of the parking. No matter how fine grained the locking strategy becomes, it will always hit that point. I think the right solution is to let the subsystem event hook become aware of this situation. If events are received while subsystems is still initializing, they will be stored and handled asynchronously once initialization is complete. Otherwise, the events will continue to be handled synchronously.
Another (simpler) solution would have been to simply handle all events asynchronously in the hook; however, this causes 3 of the 243 OSGi CT tests to fail. I believe these tests are too strict, but it might take a while to convince the EEG of that, so I'll go with a solution that can be counted on for now.
was (Author: jwross@us.ibm.com):
The crux of the issue is that something is reacting to the root subsystem service registration (i.e. the initialization of subsystems) by spawning a new thread that installs a bundle. That something then parks on a future waiting for the other thread to finish before continuing. The subsystem bundle event hook reacts to the bundle installation to ensure it gets assigned to the proper subsystem (i.e. isolation scope). However, the bundle event hook cannot proceed because the subsystems initialization has not completed. Even though there are two different threads involved, the deadlock still occurs because of the parking. So the solution mentioned in comment 6 will not work because no matter how fine grained the locking strategy becomes, it will always hit that point. I think the right solution is to let the subsystem event hook become aware of this situation. If events are received while subsystems is still initializing, they will be stored and handled asynchronously once initialization is complete. Otherwise, the events will continue to be handled synchronously.
Another (simpler) solution would have been to simply handle all events asynchronously in the hook; however, this causes 3 of the 243 OSGi CT tests to fail. I believe these tests are too strict, but it might take a while to convince the EEG of that, so I'll go with a solution that can be counted on for now.
> Deadlock between Subsystems EventHook and Activator
> ---------------------------------------------------
>
> Key: ARIES-982
> URL: https://issues.apache.org/jira/browse/ARIES-982
> Project: Aries
> Issue Type: Bug
> Components: Subsystem
> Affects Versions: 0.4
> Reporter: Mark Nuttall
>
> We're sometimes seeing a deadlock between one thread that's passed through
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/SubsystemServiceRegistrar.register(SubsystemServiceRegistrar.java:69)
> 5XESTACKTRACE (entered lock: org/apache/aries/subsystem/core/internal/SubsystemServiceRegistrar@0xD6FEEAA0, entry count: 1)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/SubsystemResourceInstaller.installAriesSubsystem(SubsystemResourceInstaller.java:96)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/SubsystemResourceInstaller.install(SubsystemResourceInstaller.java:40)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/Subsystems.getRootSubsystem(Subsystems.java:130)
> 5XESTACKTRACE (entered lock: org/apache/aries/subsystem/core/internal/Subsystems@0xD6FEEAB0, entry count: 1)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/Activator.activate(Activator.java:167)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/Activator.addingService(Activator.java:263)
> 5XESTACKTRACE (entered lock: org/apache/aries/subsystem/core/internal/Activator@0xD6C83A70, entry count: 1)
> and another,
> 3XMTHREADINFO "Blueprint Extender: 2" J9VMThread:0x083A9800, j9thread_t:0x087B373C, java/lang/Thread:0xD6346650, state:B, prio=5
> 3XMTHREADINFO1 (native thread ID:0x770F, native priority:0x5, native policy:UNKNOWN)
> 3XMTHREADINFO2 (native stack address range from:0xD0278000, to:0xD02B9000, size:0x41000)
> 3XMTHREADBLOCK Blocked on: org/apache/aries/subsystem/core/internal/Activator@0xD6C83A70 Owned by: "Blueprint Extender: 3" (J9VMThread:0x087D5D00, java/lang/Thread:0xD66F2280)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/BundleEventHook.handleExplicitlyInstalledBundleBundleContext(BundleEventHook.java:55)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/BundleEventHook.handleInstalledEvent(BundleEventHook.java:93)
> 4XESTACKTRACE at org/apache/aries/subsystem/core/internal/BundleEventHook.event(BundleEventHook.java:41)
> The problem looks to be caused by the call to Activator.getInstance() within BundleEventHook.handleExplicitlyInstalledBundleBundleContext(). One option would be to move that call into the BundleEventHook() constructor.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira