[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958842#comment-13958842
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
Hi
when you say it hangs does it block completely or just block for a moment?
which kind of machine is it?
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0 (a
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958867#comment-13958867
]
Ron Smeral commented on DELTASPIKE-558:
---
It hangs indefinitely, I've seen it hanging for 5 hours.
jstack doesn't show a deadlock, but obviously, there is an unfortunate
combination of locks and waits somewhere in there.
I don't know what the hardware is, but at least one of the configurations
tested had a SPARC processor, and the OS is Solaris 10 and 11.
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958890#comment-13958890
]
Ron Smeral commented on DELTASPIKE-558:
---
OK, so it appears it is a 128-core beast based on SPARC T3-1 CPUs.
Runtime.getRuntime().availableProcessors() also reports 128.
OpenEJB version is the one used in DS 0.5 and 0.6 (happened in both) and I see
version 4.5.1 defined in both in cdictrl/impl-openejb/pom.xml.
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13958904#comment-13958904
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
can you try with openejb 4.6.0 we changed a bit this part since on som eOS it
was not working that well
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0 (a
[jira] [Commented] (DELTASPIKE-558) OpenEJB-ContainerControl tests randomly lock up on Solaris
[
https://issues.apache.org/jira/browse/DELTASPIKE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13959650#comment-13959650
]
Romain Manni-Bucau commented on DELTASPIKE-558:
---
yes sounds consistent we what we did.
wonder if ds shouldnt just make openejb provided since it shouldnt force a
version.
any opinion?
OpenEJB-ContainerControl tests randomly lock up on Solaris
--
Key: DELTASPIKE-558
URL: https://issues.apache.org/jira/browse/DELTASPIKE-558
Project: DeltaSpike
Issue Type: Bug
Components: CdiControl
Affects Versions: 0.6
Environment: Solaris 10/11
Java 1.6/1.8
Reporter: Ron Smeral
The tests for OpenEJB-ContainerControl often hang on Solaris.
Noticed on Solaris 10/11 with Java 1.6/1.8.
Output of jstack suggests that this might be an issue of the OpenEJB
container itself.
jstack output:
{noformat}
2014-04-03 08:07:18
Full thread dump Java HotSpot(TM) Server VM (24.51-b03 mixed mode):
Attach Listener daemon prio=3 tid=0x00db3400 nid=0xa8 waiting on condition
[0x]
java.lang.Thread.State: RUNNABLE
RetryTimer daemon prio=3 tid=0x00996000 nid=0x24 in Object.wait()
[0xb2eef000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead92c58 (a java.util.TaskQueue)
at java.lang.Object.wait(Object.java:503)
at java.util.TimerThread.mainLoop(Timer.java:526)
- locked 0xead92c58 (a java.util.TaskQueue)
at java.util.TimerThread.run(Timer.java:505)
Service Thread daemon prio=3 tid=0x00231c00 nid=0x22 runnable [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread1 daemon prio=3 tid=0x0023 nid=0x21 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
C2 CompilerThread0 daemon prio=3 tid=0x0022d800 nid=0x20 waiting on
condition [0x]
java.lang.Thread.State: RUNNABLE
Signal Dispatcher daemon prio=3 tid=0x0022c000 nid=0x1f runnable
[0x]
java.lang.Thread.State: RUNNABLE
Finalizer daemon prio=3 tid=0x0021a800 nid=0x1e in Object.wait()
[0xb382f000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
- locked 0xead9ed68 (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
Reference Handler daemon prio=3 tid=0x00214800 nid=0x1d in Object.wait()
[0xb38bf000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on 0xead93db8 (a java.lang.ref.Reference$Lock)
at java.lang.Object.wait(Object.java:503)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
- locked 0xead93db8 (a java.lang.ref.Reference$Lock)
main prio=3 tid=0x00028c00 nid=0x2 waiting on condition [0xfdf4c000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for 0xead91ce0 (a
java.util.concurrent.Semaphore$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303)
at java.util.concurrent.Semaphore.acquire(Semaphore.java:472)
at org.apache.openejb.Core.clinit(Core.java:138)
at
org.apache.openejb.core.LocalInitialContext.clinit(LocalInitialContext.java:51)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at
org.apache.openejb.core.LocalInitialContextFactory.getLocalInitialContext(LocalInitialContextFactory.java:81)
at
org.apache.openejb.core.LocalInitialContextFactory.getInitialContext(LocalInitialContextFactory.java:41)
at
javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)
at
javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307)
at javax.naming.InitialContext.init(InitialContext.java:242)
at javax.naming.InitialContext.init(InitialContext.java:216)
at
org.apache.deltaspike.cdise.openejb.OpenEjbContainerControl.boot(OpenEjbContainerControl.java:99)
- locked 0xead9f1f0 (a
