[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on JBTM-1865:
-----------------------------------------------
you're right, I'll update the error code accordingly and report back here, if that solves the issue
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1866) HeuristicMixedException reported to client, although backends don't support heuristic completion
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1866?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1866:
-----------------------------------
You are seeing the correct behaviour. One of your RMs is committing and the other has rolled back (RBCOMMFAIL). Therefore, we are in a mixed situation (please refer to the relevant specification documents to see what I mean). RBCOMMFAIL is not an indication that the RM has committed. The XA specification is clear on that fact.
> HeuristicMixedException reported to client, although backends don't support heuristic completion
> ------------------------------------------------------------------------------------------------
>
> Key: JBTM-1866
> URL: https://issues.jboss.org/browse/JBTM-1866
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> this bug is related to:
> https://issues.jboss.org/browse/JBTM-1865
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, the other
> issue is filed as JBTM-1865
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the second database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> The first branch was successfully committed (as it should be spec.)
> But now things go awry:
> 1. The client receives a HeuristicMixedException, although the backend
> does not support heuristic completion at all, i.e. there should be no Heuristic* exception be thrown
> The correct behavior is, to report the transaction as success to the client, commit all other branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1865:
-----------------------------------
You are seeing the correct behaviour. Please go and re-read the X/Open XA specification. Here's a brief piece to help understand:
[XA_RB∗]
The resource manager did not commit the work done on behalf of the transaction branch. Upon return, the resource manager has rolled back the branch’s work and has released all held resources.
And XA_RBCOMFAIL means: A communication failure occurred within the resource manager.
Since we know the commit has failed, we rollback the transaction. Just because an application level commit has been called on the transaction does not mean the transaction has committed.
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Mark Little (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Mark Little commented on JBTM-1865:
-----------------------------------
I'll add that if your database is committing the work done on the branch and returning RBCOMMFAIL then it is not compliant with the XA specification.
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1866) HeuristicMixedException reported to client, although backends don't support heuristic completion
by Christian von Kutzleben (JIRA)
Christian von Kutzleben created JBTM-1866:
---------------------------------------------
Summary: HeuristicMixedException reported to client, although backends don't support heuristic completion
Key: JBTM-1866
URL: https://issues.jboss.org/browse/JBTM-1866
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Core
Affects Versions: 4.17.4
Reporter: Christian von Kutzleben
Assignee: Tom Jenkinson
this bug is related to:
https://issues.jboss.org/browse/JBTM-1865
While testing recovery and transaction failures we came across
two related issues, the test scenario is almost the same, the other
issue is filed as JBTM-1865
Scenario:
2 enlisted XAResources (one for each database used by the test),
The prepare phase is successful.
We crash the second database server during the XAResource.commit invocation,
_after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
The first branch was successfully committed (as it should be spec.)
But now things go awry:
1. The client receives a HeuristicMixedException, although the backend
does not support heuristic completion at all, i.e. there should be no Heuristic* exception be thrown
The correct behavior is, to report the transaction as success to the client, commit all other branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/JBTM-1865?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on JBTM-1865:
-----------------------------------------------
the other issue mentioned is JBTM-1866
> Transaction reported to be rolled back, although committed with one participant
> -------------------------------------------------------------------------------
>
> Key: JBTM-1865
> URL: https://issues.jboss.org/browse/JBTM-1865
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.17.4
> Reporter: Christian von Kutzleben
> Assignee: Tom Jenkinson
>
> While testing recovery and transaction failures we came across
> two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
> Scenario:
> 2 enlisted XAResources (one for each database used by the test),
> The prepare phase is successful.
> We crash the first database server during the XAResource.commit invocation,
> _after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
> The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
> By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
> But now things go awry:
> 1. There is a XAResource.rollback() issued to the second XAResource.
> 2. The client receives a EJBTransactionRolledbackException, although
> one branch has been completed.
> Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
> The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1865) Transaction reported to be rolled back, although committed with one participant
by Christian von Kutzleben (JIRA)
Christian von Kutzleben created JBTM-1865:
---------------------------------------------
Summary: Transaction reported to be rolled back, although committed with one participant
Key: JBTM-1865
URL: https://issues.jboss.org/browse/JBTM-1865
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transaction Core
Affects Versions: 4.17.4
Reporter: Christian von Kutzleben
Assignee: Tom Jenkinson
While testing recovery and transaction failures we came across
two related issues, the test scenario is almost the same, I'll file the second issue shortly and update this ticket accordingly.
Scenario:
2 enlisted XAResources (one for each database used by the test),
The prepare phase is successful.
We crash the first database server during the XAResource.commit invocation,
_after_ it has committed it's branch, right before the control flow would return to the XAResource (which as a result throws a XAException.XA_RBCOMMFAIL).
The TM can not know at this point in time, whether the database successfully committed the transaction or not. In this particular case, all changes have been committed.
By definition of the 2PC protocol, the transaction should be considered as "to be committed", because the prepare phase has ended successfully.
But now things go awry:
1. There is a XAResource.rollback() issued to the second XAResource.
2. The client receives a EJBTransactionRolledbackException, although
one branch has been completed.
Note, that our database does not support heuristical completion of a branch at all, i.e. there should be no Heuristic* exception be thrown either.
The correct behavior is, to report the transaction as success to the client, commit all branches. All XAResources which failed during XAResource.commit() are supposed to be recovered in future.
--
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
11 years, 5 months
[JBoss JIRA] (JBTM-1857) TestBASubordinateCrashDuringComplete hangs
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-1857?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-1857:
-------------------------------------
If this issue is reopened we need to consider setting up this a repeating job with log to console rather than file
> TestBASubordinateCrashDuringComplete hangs
> ------------------------------------------
>
> Key: JBTM-1857
> URL: https://issues.jboss.org/browse/JBTM-1857
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Testing, XTS
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 4.17.8
>
>
> http://172.17.131.2/job/jbossts-EAP61-jdbcobjectstore/DB_TYPE=oracle,jdk=...
> {code}
> Running com.arjuna.qa.junit.TestBASubordinateCrashDuringComplete
> 2013-07-22 07:07:16
> Full thread dump Java HotSpot(TM) 64-Bit Server VM (20.12-b01 mixed mode):
> "Thread-104" prio=10 tid=0x00007fcab126c000 nid=0x487f runnable [0x00007fcaaeb46000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:220)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
> - locked <0x00000000dd968c88> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:167)
> at java.io.BufferedReader.fill(BufferedReader.java:136)
> at java.io.BufferedReader.readLine(BufferedReader.java:299)
> - locked <0x00000000dd968c88> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:362)
> at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:129)
> "Thread-103" prio=10 tid=0x00007fcab0823800 nid=0x487d runnable [0x00007fcaaed48000]
> java.lang.Thread.State: RUNNABLE
> at java.io.FileInputStream.readBytes(Native Method)
> at java.io.FileInputStream.read(FileInputStream.java:220)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
> - locked <0x00000000dd96ada0> (a java.io.BufferedInputStream)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
> - locked <0x00000000dd96adf8> (a java.io.InputStreamReader)
> at java.io.InputStreamReader.read(InputStreamReader.java:167)
> at java.io.BufferedReader.fill(BufferedReader.java:136)
> at java.io.BufferedReader.readLine(BufferedReader.java:299)
> - locked <0x00000000dd96adf8> (a java.io.InputStreamReader)
> at java.io.BufferedReader.readLine(BufferedReader.java:362)
> at org.codehaus.plexus.util.cli.StreamPumper.run(StreamPumper.java:129)
> "process reaper" daemon prio=10 tid=0x00007fcab106f000 nid=0x487b runnable [0x00007fcaaec47000]
> java.lang.Thread.State: RUNNABLE
> at java.lang.UNIXProcess.waitForProcessExit(Native Method)
> at java.lang.UNIXProcess.access$900(UNIXProcess.java:20)
> at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132)
> "ThreadedStreamConsumer" prio=10 tid=0x00007fcab030f000 nid=0x487a waiting on condition [0x00007fcaaee49000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dd9c4688> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at org.apache.maven.surefire.util.internal.Java15BlockingQueue.take(Java15BlockingQueue.java:40)
> at org.apache.maven.plugin.surefire.booterclient.output.ThreadedStreamConsumer$Pumper.run(ThreadedStreamConsumer.java:68)
> at java.lang.Thread.run(Thread.java:662)
> "resolver-5" daemon prio=10 tid=0x00007fcab0f86000 nid=0x45fc waiting on condition [0x00007fcaaef4a000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dab57588> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:662)
> "resolver-4" daemon prio=10 tid=0x00007fcab0c05800 nid=0x44a1 waiting on condition [0x00007fcaaf04b000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dab57588> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:662)
> "resolver-3" daemon prio=10 tid=0x00007fcab0c11800 nid=0x44a0 waiting on condition [0x00007fcaaf14c000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dab57588> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:662)
> "resolver-2" daemon prio=10 tid=0x00007fcab0981800 nid=0x449f waiting on condition [0x00007fcaaf24d000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dab57588> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:662)
> "resolver-1" daemon prio=10 tid=0x00007fcab0dff800 nid=0x449e waiting on condition [0x00007fcaaf65f000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000dab57588> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:156)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:1987)
> at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:399)
> at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:947)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
> at java.lang.Thread.run(Thread.java:662)
> "Low Memory Detector" daemon prio=10 tid=0x00007fcab0088000 nid=0x449a runnable [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread1" daemon prio=10 tid=0x00007fcab0085800 nid=0x4499 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "C2 CompilerThread0" daemon prio=10 tid=0x00007fcab0083800 nid=0x4498 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Signal Dispatcher" daemon prio=10 tid=0x00007fcab0081000 nid=0x4497 waiting on condition [0x0000000000000000]
> java.lang.Thread.State: RUNNABLE
> "Finalizer" daemon prio=10 tid=0x00007fcab0064800 nid=0x4496 in Object.wait() [0x00007fcaafc65000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000daaa0460> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
> - locked <0x00000000daaa0460> (a java.lang.ref.ReferenceQueue$Lock)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
> "Reference Handler" daemon prio=10 tid=0x00007fcab0062800 nid=0x4495 in Object.wait() [0x00007fcaafd66000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000daaa0500> (a java.lang.ref.Reference$Lock)
> at java.lang.Object.wait(Object.java:485)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
> - locked <0x00000000daaa0500> (a java.lang.ref.Reference$Lock)
> "main" prio=10 tid=0x00007fcab0007000 nid=0x4493 in Object.wait() [0x00007fcab7e58000]
> java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x00000000dd96aeb8> (a java.lang.UNIXProcess)
> at java.lang.Object.wait(Object.java:485)
> at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
> - locked <0x00000000dd96aeb8> (a java.lang.UNIXProcess)
> at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:151)
> at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:88)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.fork(ForkStarter.java:191)
> at org.apache.maven.plugin.surefire.booterclient.ForkStarter.run(ForkStarter.java:98)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeProvider(AbstractSurefireMojo.java:199)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAllProviders(AbstractSurefireMojo.java:176)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:134)
> at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:97)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:107)
> 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:319)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:534)
> 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:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> 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=0x00007fcab005c000 nid=0x4494 runnable
> "VM Periodic Task Thread" prio=10 tid=0x00007fcab0093000 nid=0x449b waiting on condition
> JNI global references: 1080
> {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
11 years, 5 months