[
https://issues.apache.org/jira/browse/ARIES-982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526389#comment-13526389
]
John Ross commented on ARIES-982:
---------------------------------
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
