[JBoss JIRA] (JBTM-1840) Incorrect handling of multi-threaded access to JCA connections
by Eytan David (JIRA)
[ https://issues.jboss.org/browse/JBTM-1840?page=com.atlassian.jira.plugin.... ]
Eytan David updated JBTM-1840:
------------------------------
Attachment: JCA_Deadlock.txt
> Incorrect handling of multi-threaded access to JCA connections
> ---------------------------------------------------------------
>
> Key: JBTM-1840
> URL: https://issues.jboss.org/browse/JBTM-1840
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 6.0.0.Final
> Environment: Red Hat Linux, Jboss EAP 6.0
> Reporter: Eytan David
> Assignee: Tom Jenkinson
> Attachments: JCA_Deadlock.txt
>
>
> The issue JBPAPP-5596 which according to the documentation should have been resolved in Jboss EAP 5.1.1, still occurs in EAP 6.0
> The case describes a situation in which a long transaction (in a service handled by JTA) is set to be rolled back, but gets into a dead lock with the reaper thread.
> Deadlock as described in the stack trace:
> Found one Java-level deadlock:
> =============================
> "Thread-20":
> waiting for ownable synchronizer 0xb22a2e58, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
> which is held by "http-127.0.0.1-8080-1"
> "http-127.0.0.1-8080-1":
> waiting to lock monitor 0x4e200ef4 (object 0xaa937ab0, a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction),
> which is held by "Thread-20"
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1840) Incorrect handling of multi-threaded access to JCA connections
by Eytan David (JIRA)
Eytan David created JBTM-1840:
---------------------------------
Summary: Incorrect handling of multi-threaded access to JCA connections
Key: JBTM-1840
URL: https://issues.jboss.org/browse/JBTM-1840
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCA
Affects Versions: 6.0.0.Final
Environment: Red Hat Linux, Jboss EAP 6.0
Reporter: Eytan David
Assignee: Tom Jenkinson
The issue JBPAPP-5596 which according to the documentation should have been resolved in Jboss EAP 5.1.1, still occurs in EAP 6.0
The case describes a situation in which a long transaction (in a service handled by JTA) is set to be rolled back, but gets into a dead lock with the reaper thread.
Deadlock as described in the stack trace:
Found one Java-level deadlock:
=============================
"Thread-20":
waiting for ownable synchronizer 0xb22a2e58, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
which is held by "http-127.0.0.1-8080-1"
"http-127.0.0.1-8080-1":
waiting to lock monitor 0x4e200ef4 (object 0xaa937ab0, a com.arjuna.ats.internal.jta.transaction.arjunacore.AtomicAction),
which is held by "Thread-20"
--
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
12 years, 8 months
[JBoss JIRA] (JBTM-1771) Source directory names of the rest-tx modules need improving
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1771?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1771:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
both pulls passed
> Source directory names of the rest-tx modules need improving
> ------------------------------------------------------------
>
> Key: JBTM-1771
> URL: https://issues.jboss.org/browse/JBTM-1771
> Project: JBoss Transaction Manager
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 5.0.0.M3
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.0.0.M4
>
>
> The source directory names of the REST modules is confusing and does not accurately reflect what they are for. Currently we have:
> {noformat}
> rest-tx
> tx
> integration
> util
> webservice
> {noformat}
> which I'd like to rationalize to:
> {noformat}
> rts (RESTful Transaction Service)
> at (Atomic Transactions)
> tx (the JAX-RS service that implements the spec)
> integration (simple API for writing Java based participants)
> util (various utility methods for making it easy to conform to the spec)
> webservice (bundles tx as a deployable war)
> {noformat}
> (and later on we'll add jdi at the same level as at).
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-1748) Orphaned QA RecoveryManager causes RecoveryManagerStartStopTest hangs (possibly others)
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-1748?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-1748:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
I've added a section to narayana.sh to terminate any old testsuite processes at the start of a CI job
> Orphaned QA RecoveryManager causes RecoveryManagerStartStopTest hangs (possibly others)
> ---------------------------------------------------------------------------------------
>
> Key: JBTM-1748
> URL: https://issues.jboss.org/browse/JBTM-1748
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, Transaction Core
> Reporter: Gytis Trikleris
> Assignee: Michael Musgrove
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> http://172.17.131.2/job/narayana/TESTS=MAIN,jdk=jdk7.latest,label=linux/9...
> {code}
> Running com.hp.mwtests.ts.arjuna.recovery.RecoveryManagerStartStopTest
> 2013-06-06 10:34:56
> Full thread dump Java HotSpot(TM) Client VM (23.5-b02 mixed mode):
> "Periodic Recovery" prio=10 tid=0x08bd2000 nid=0x2ec6 in Object.wait() [0xa1448000]
> java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa2047fc8> (a java.lang.Object)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doPeriodicWait(PeriodicRecovery.java:672)
> at com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:392)
> - locked <0xa2047fc8> (a java.lang.Object)
> "Thread-0" daemon prio=10 tid=0x0876c000 nid=0x2ec5 runnable [0xa14a9000]
> java.lang.Thread.State: RUNNABLE
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
> at java.net.ServerSocket.implAccept(ServerSocket.java:522)
> at java.net.ServerSocket.accept(ServerSocket.java:490)
> at org.jboss.byteman.agent.TransformListener.run(TransformListener.java:133)
> "Attach Listener" daemon prio=10 tid=0x0867b800 nid=0x2ec4 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Service Thread" daemon prio=10 tid=0x084ca800 nid=0x2ec2 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread0" daemon prio=10 tid=0x084bfc00 nid=0x2ec1 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x084be400 nid=0x2ec0 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0x08480000 nid=0x2ebf in Object.wait() [0xa1a4d000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa73fb498> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0xa73fb498> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
> "Reference Handler" daemon prio=10 tid=0x0847e400 nid=0x2ebe in Object.wait() [0xa1a9e000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa73fb520> (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 <0xa73fb520> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0x08403000 nid=0x2ebb in Object.wait() [0xb7f1a000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0xa22c9cf0> (a org.jboss.byteman.synchronization.Rendezvous)
> at java.lang.Object.wait(Object.java:503)
> at org.jboss.byteman.synchronization.Rendezvous.rendezvous(Rendezvous.java:69)
> at org.jboss.byteman.rule.helper.Helper.rendezvous(Helper.java:663)
> - locked <0xa22c9cf0> (a org.jboss.byteman.synchronization.Rendezvous)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.jboss.byteman.rule.expression.MethodExpression.interpret(MethodExpression.java:342)
> at org.jboss.byteman.rule.Action.interpret(Action.java:144)
> at org.jboss.byteman.rule.helper.InterpretedHelper.fire(InterpretedHelper.java:169)
> at org.jboss.byteman.rule.helper.InterpretedHelper.execute0(InterpretedHelper.java:137)
> at org.jboss.byteman.rule.helper.InterpretedHelper.execute(InterpretedHelper.java:100)
> at org.jboss.byteman.rule.Rule.execute(Rule.java:682)
> at org.jboss.byteman.rule.Rule.execute(Rule.java:651)
> at com.hp.mwtests.ts.arjuna.recovery.RecoveryManagerStartStopTest.testStartStop(RecoveryManagerStartStopTest.java:89)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.jboss.byteman.contrib.bmunit.BMUnitRunner$1.evaluate(BMUnitRunner.java:100)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
> "VM Thread" prio=10 tid=0x08478c00 nid=0x2ebd runnable
> "VM Periodic Task Thread" prio=10 tid=0x084cc800 nid=0x2ec3 waiting on condition
> JNI global references: 361
> Heap
> def new generation total 4928K, used 3810K [0xa1e40000, 0xa2390000, 0xa7390000)
> eden space 4416K, 78% used [0xa1e40000, 0xa21a6590, 0xa2290000)
> from space 512K, 64% used [0xa2290000, 0xa22e2350, 0xa2310000)
> to space 512K, 0% used [0xa2310000, 0xa2310000, 0xa2390000)
> tenured generation total 10944K, used 1639K [0xa7390000, 0xa7e40000, 0xb1e40000)
> the space 10944K, 14% used [0xa7390000, 0xa7529e60, 0xa752a000, 0xa7e40000)
> compacting perm gen total 12288K, used 5426K [0xb1e40000, 0xb2a40000, 0xb5e40000)
> the space 12288K, 44% used [0xb1e40000, 0xb238c8a0, 0xb238ca00, 0xb2a40000)
> No shared spaces configured.
> 2013-06-06 10:34:56
> Full thread dump Java HotSpot(TM) Client VM (23.5-b02 mixed mode):
> "Thread-158" prio=10 tid=0x09117c00 nid=0x2ebc runnable [0x851af000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:242)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
> - locked <0x86b23930> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
> - locked <0x86b28698> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:154)
> at java.io.BufferedReader.readLine(BufferedReader.java:317)
> - locked <0x86b28698> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:382)
> at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:129)
> "Thread-157" prio=10 tid=0x0911b000 nid=0x2eb9 runnable [0x85080000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:242)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:273)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:334)
> - locked <0x86b218a0> (a java.lang.UNIXProcess$ProcessPipeInputStream)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:283)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:325)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:177)
> - locked <0x86b25be8> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:154)
> at java.io.BufferedReader.readLine(BufferedReader.java:317)
> - locked <0x86b25be8> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:382)
> at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:129)
> "ThreadedStreamConsumer" prio=10 tid=0x0911a800 nid=0x2eb7 waiting on condition [0x8502f000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x86b04450> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at org.apache.maven.plugin.surefire.util.internal.Java15BlockingQueue.take(Java15BlockingQueue.java:41)
> at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:68)
> at java.lang.Thread.run(Thread.java:722)
> "pool-2-thread-1" prio=10 tid=0x09df6c00 nid=0x29dd in Object.wait() [0x85251000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x86b1f548> (a java.lang.UNIXProcess)
> at java.lang.Object.wait(Object.java:503)
> at java.lang.UNIXProcess.waitFor(UNIXProcess.java:210)
> - locked <0x86b1f548> (a java.lang.UNIXProcess)
> at org.codehaus.plexus.util.cli.CommandLineUtils$1.call(CommandLineUtils.java:173)
> at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:114)
> at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:280)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.access$100(ForkStarter.java:75)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:163)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter$1.call(ForkStarter.java:160)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "resolver-4" daemon prio=10 tid=0x09adbc00 nid=0x29a1 waiting on condition [0x8530b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x90aee3e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "resolver-3" daemon prio=10 tid=0x09a88000 nid=0x29a0 waiting on condition [0x8535c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x90aee3e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "resolver-2" daemon prio=10 tid=0x09ad9800 nid=0x299f waiting on condition [0x853ad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x90aee3e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "resolver-1" daemon prio=10 tid=0x09ac3800 nid=0x299e waiting on condition [0x853fe000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x90aee3e0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "process reaper" daemon prio=10 tid=0x09580800 nid=0x299d runnable [0x854bd000]
> java.lang.Thread.State: RUNNABLE
> at java.lang.UNIXProcess.waitForProcessExit(Native Method)
> at java.lang.UNIXProcess.access$200(UNIXProcess.java:54)
> at java.lang.UNIXProcess$3.run(UNIXProcess.java:174)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:722)
> "Service Thread" daemon prio=10 tid=0x090f8000 nid=0x299a runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "C1 CompilerThread0" daemon prio=10 tid=0x090ed800 nid=0x2999 waiting on condition [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x090ebc00 nid=0x2998 runnable [0x00000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0x090adc00 nid=0x2997 in Object.wait() [0x85938000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x90963020> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
> - locked <0x90963020> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
> "Reference Handler" daemon prio=10 tid=0x090ac000 nid=0x2996 in Object.wait() [0x85989000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x909630a8> (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 <0x909630a8> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0x09030c00 nid=0x2994 waiting on condition [0xb7fa6000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x94823fe8> (a java.util.concurrent.FutureTask$Sync)
> 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.FutureTask$Sync.innerGet(FutureTask.java:248)
> at java.util.concurrent.FutureTask.get(FutureTask.java:111)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.runSuitesForkPerTestSet(ForkStarter.java:176)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:121)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:740)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:682)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:648)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:586)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:601)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
> "VM Thread" prio=10 tid=0x090a6400 nid=0x2995 runnable
> "VM Periodic Task Thread" prio=10 tid=0x090fa000 nid=0x299b waiting on condition
> JNI global references: 317
> Heap
> def new generation total 36160K, used 16947K [0x85ec0000, 0x885f0000, 0x90960000)
> eden space 32192K, 41% used [0x85ec0000, 0x86bd94f0, 0x87e30000)
> from space 3968K, 89% used [0x87e30000, 0x881a39b0, 0x88210000)
> to space 3968K, 0% used [0x88210000, 0x88210000, 0x885f0000)
> tenured generation total 80232K, used 65524K [0x90960000, 0x957ba000, 0xa5ec0000)
> the space 80232K, 81% used [0x90960000, 0x9495d328, 0x9495d400, 0x957ba000)
> compacting perm gen total 20992K, used 20780K [0xa5ec0000, 0xa7340000, 0xb5ec0000)
> the space 20992K, 98% used [0xa5ec0000, 0xa730b3c0, 0xa730b400, 0xa7340000)
> No shared spaces configured.
> {code}
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Mark Little commented on JBTM-846:
----------------------------------
After discussions with the team on the WF use case I think it either means two recovery managers or one recovery manager that can scan two different object stores. But that's an implementation detail.
> Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> ** This Jira is a work in progress - Paul to remove this message when description complete **
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
David Lloyd commented on JBTM-846:
----------------------------------
In regards to recovery - from a user perspective, I think that different people may be responsible/authorized for recovering transactions in the management system versus in the end-user application. That doesn't necessarily imply two recovery managers I guess, but I think that might be an important use case to address one way or another.
> Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> ** This Jira is a work in progress - Paul to remove this message when description complete **
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-846:
-------------------------------
Description:
** This Jira is a work in progress - Paul to remove this message when description complete **
The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
This will require removal of much of the static configuration state such as StateManager references to ObjectStore
was:
This will require removal of much of the static configuration state such as StateManager references to ObjectStore
The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
> Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> ** This Jira is a work in progress - Paul to remove this message when description complete **
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-846:
-------------------------------
Summary: Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM (was: Allow transactional MSC and WildFly EJB container to operate with different configurations in a single JVM)
> Allow transactional MSC and WildFly EJB container to operate with different configurations for transaction/recovery manager in a single JVM
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months
[JBoss JIRA] (JBTM-846) Allow transactional MSC and WildFly EJB container to operate with different configurations in a single JVM
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-846?page=com.atlassian.jira.plugin.s... ]
Tom Jenkinson updated JBTM-846:
-------------------------------
Summary: Allow transactional MSC and WildFly EJB container to operate with different configurations in a single JVM (was: Allow multiple transaction managers with different configurations to operate in a single JVM)
> Allow transactional MSC and WildFly EJB container to operate with different configurations in a single JVM
> ----------------------------------------------------------------------------------------------------------
>
> Key: JBTM-846
> URL: https://issues.jboss.org/browse/JBTM-846
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA, JTS, Recovery, Transaction Core, XTS
> Reporter: Tom Jenkinson
> Assignee: Paul Robinson
> Fix For: 5.0.0.Final
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> This will require removal of much of the static configuration state such as StateManager references to ObjectStore
> The use case provided for this is to run a separate transaction/recovery manager for Transactional MSC to the one that WildFly is using for its (JTA/JTS) EJB container.
--
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
12 years, 9 months