[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1712:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> made a comment on [bug 968125|https://bugzilla.redhat.com/show_bug.cgi?id=968125]
Do not set to MODIFIED. It means the fix has made it onto the 6.1.x branch.
Needs a PR to move to POST.
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4, 5.0.0.M2
> Reporter: Jonathan Halliday
> Assignee: Mark Little
> Fix For: 5.0.0.M3
>
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
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, 10 months
[JBoss JIRA] (JBTM-1712) perf problem in FileSystemStore.openAndLock
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1712?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1712:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 968125|https://bugzilla.redhat.com/show_bug.cgi?id=968125] from MODIFIED to ASSIGNED
> perf problem in FileSystemStore.openAndLock
> -------------------------------------------
>
> Key: JBTM-1712
> URL: https://issues.jboss.org/browse/JBTM-1712
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Affects Versions: 4.16.4, 5.0.0.M2
> Reporter: Jonathan Halliday
> Assignee: Mark Little
> Fix For: 5.0.0.M3
>
>
> if(!file.exits())
> {
> if(createHierarchy(file))
> incorrectly calls the expensive (because synchronized) createHierarchy method in the common case where the file does not exist (because it's a uniq named new tx record) but the directory hierarchy does (because it's the create-once hashed dir tree). This causes excessive contention on the FileSystemStore instance object monitor lock. Should probably be something more like
> if(!file.getParent().exists())
> {
> if(createHierarchy(file))
--
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, 10 months
[JBoss JIRA] (JBTM-1171) improve XAResource preparefailed logging
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTM-1171?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JBTM-1171:
-----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> changed the Status of [bug 959462|https://bugzilla.redhat.com/show_bug.cgi?id=959462] from MODIFIED to ASSIGNED
> improve XAResource preparefailed logging
> ----------------------------------------
>
> Key: JBTM-1171
> URL: https://issues.jboss.org/browse/JBTM-1171
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: JTA
> Affects Versions: 4.6.1.CP12
> Reporter: Jonathan Halliday
> Assignee: Michael Musgrove
> Fix For: 4.6.1.CP13, 4.17.5, 5.0.0.M4
>
>
> com.arjuna.ats.internal.jta.resources.arjunacore.preparefailed does not log the underlying XA exception. In cases where e.g. db constraints are deferred to tx commit time, such errors can contain useful information.
> Note that non-deferred constraints are covered by JBTM-575 as the problem manifests at the earlier beforeCompletion (i.e. sql flush) stage.
--
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, 10 months
[JBoss JIRA] (JBTM-1762) TX TestTransactions::test_rollback failed with un-expect TX_FAIL
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1762?page=com.atlassian.jira.plugin.... ]
Amos Feng edited comment on JBTM-1762 at 6/6/13 9:49 PM:
---------------------------------------------------------
the success build return the following
{code}
2013-05-29 09:21:50,694 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 164 bytes
2013-05-29 09:21:50,696 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
Connection: keep-alive
Content-Length: 84
<html><head><title>Error</title></head><body>412 - Precondition Failed</body></html>
2013-05-29 09:21:50,698 [0x57fd3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 412 Precondition Failed
2013-05-29 09:21:50,700 [0x57fd3f0] DEBUG (HttpClient :194 ) - Connection: keep-alive
2013-05-29 09:21:50,702 [0x57fd3f0] DEBUG (HttpClient :194 ) - Content-Length: 84
2013-05-29 09:21:50,704 [0x57fd3f0] DEBUG (HttpClient :220 ) - status_code:412
2013-05-29 09:21:50,706 [0x57fd3f0] DEBUG (HttpClient :222 ) - content: <html><head><title>Error</title></head><body>412 - Precondition Failed</body></html>
2013-05-29 09:21:50,708 [0x57fd3f0] DEBUG (TxHttpControl :299 ) - do_end: HTTP status: 412 resp: <html><head><title>Error</title></head><body>412 - Precondition Failed</body></html> nread: 84
2013-05-29 09:21:50,714 [0x57fd3f0] DEBUG (TxHttpControl :254 ) - http_to_tx_status ad><title>Error</title></head><body>412 - Precondition Failed</body></html> -> 0
2013-05-29 09:21:50,716 [0x57fd3f0] DEBUG (TxControl :66 ) - end: outcome: -2
{code}
was (Author: zhfeng):
the success build return the following
{code}
2013-05-29 09:21:50,694 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 164 bytes
2013-05-29 09:21:50,696 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
Connection: keep-alive
Content-Length: 84
<html><head><title>Error</title></head><body>412 - Precondition Failed</body></html>
{code}
> TX TestTransactions::test_rollback failed with un-expect TX_FAIL
> ----------------------------------------------------------------
>
> Key: JBTM-1762
> URL: https://issues.jboss.org/browse/JBTM-1762
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> {noformat}
> [exec] 1) test: TestTransactions::test_rollback (F) line: 288 /home/hudson/workspace/blacktie-linux32/tx/src/test/cpp/TestTransactions.cxx
> [exec] equality assertion failed
> [exec] - Expected: -2
> [exec] - Actual : -7
> {noformat}
> It looks like the TM server returns code 412 and no content. so tx_commit() returns TX_FAIL but expects TX_ROLLBACK.
> {code}
> 2013-06-07 08:34:08,732 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 79 bytes
> 2013-06-07 08:34:08,734 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
> Connection: keep-alive
> Content-Length: 0
> 2013-06-07 08:34:08,736 [0x57fd3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 412 Precondition Failed
> 2013-06-07 08:34:08,738 [0x57fd3f0] DEBUG (HttpClient :194 ) - Connection: keep-alive
> 2013-06-07 08:34:08,739 [0x57fd3f0] DEBUG (HttpClient :194 ) - Content-Length: 0
> 2013-06-07 08:34:08,741 [0x57fd3f0] DEBUG (HttpClient :220 ) - status_code:412
> 2013-06-07 08:34:08,743 [0x57fd3f0] DEBUG (TxHttpControl :299 ) - do_end: HTTP status: 412 resp:
> 2013-06-07 08:34:08,745 [0x57fd3f0] DEBUG (TxControl :66 ) - end: outcome: -7
> {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, 10 months
[JBoss JIRA] (JBTM-1762) TX TestTransactions::test_rollback failed with un-expect TX_FAIL
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1762?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-1762:
---------------------------------
the success build return the following
{code}
2013-05-29 09:21:50,694 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 164 bytes
2013-05-29 09:21:50,696 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
Connection: keep-alive
Content-Length: 84
<html><head><title>Error</title></head><body>412 - Precondition Failed</body></html>
{code}
> TX TestTransactions::test_rollback failed with un-expect TX_FAIL
> ----------------------------------------------------------------
>
> Key: JBTM-1762
> URL: https://issues.jboss.org/browse/JBTM-1762
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: BlackTie
> Reporter: Amos Feng
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> {noformat}
> [exec] 1) test: TestTransactions::test_rollback (F) line: 288 /home/hudson/workspace/blacktie-linux32/tx/src/test/cpp/TestTransactions.cxx
> [exec] equality assertion failed
> [exec] - Expected: -2
> [exec] - Actual : -7
> {noformat}
> It looks like the TM server returns code 412 and no content. so tx_commit() returns TX_FAIL but expects TX_ROLLBACK.
> {code}
> 2013-06-07 08:34:08,732 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 79 bytes
> 2013-06-07 08:34:08,734 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
> Connection: keep-alive
> Content-Length: 0
> 2013-06-07 08:34:08,736 [0x57fd3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 412 Precondition Failed
> 2013-06-07 08:34:08,738 [0x57fd3f0] DEBUG (HttpClient :194 ) - Connection: keep-alive
> 2013-06-07 08:34:08,739 [0x57fd3f0] DEBUG (HttpClient :194 ) - Content-Length: 0
> 2013-06-07 08:34:08,741 [0x57fd3f0] DEBUG (HttpClient :220 ) - status_code:412
> 2013-06-07 08:34:08,743 [0x57fd3f0] DEBUG (TxHttpControl :299 ) - do_end: HTTP status: 412 resp:
> 2013-06-07 08:34:08,745 [0x57fd3f0] DEBUG (TxControl :66 ) - end: outcome: -7
> {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, 10 months
[JBoss JIRA] (JBTM-1762) TX TestTransactions::test_rollback failed with un-expect TX_FAIL
by Amos Feng (JIRA)
Amos Feng created JBTM-1762:
-------------------------------
Summary: TX TestTransactions::test_rollback failed with un-expect TX_FAIL
Key: JBTM-1762
URL: https://issues.jboss.org/browse/JBTM-1762
Project: JBoss Transaction Manager
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: BlackTie
Reporter: Amos Feng
Assignee: Amos Feng
Fix For: 5.0.0.M4
{noformat}
[exec] 1) test: TestTransactions::test_rollback (F) line: 288 /home/hudson/workspace/blacktie-linux32/tx/src/test/cpp/TestTransactions.cxx
[exec] equality assertion failed
[exec] - Expected: -2
[exec] - Actual : -7
{noformat}
It looks like the TM server returns code 412 and no content. so tx_commit() returns TX_FAIL but expects TX_ROLLBACK.
{code}
2013-06-07 08:34:08,732 [0x57fd3f0] DEBUG (HttpClient :162 ) - receive 79 bytes
2013-06-07 08:34:08,734 [0x57fd3f0] DEBUG (HttpClient :165 ) - HTTP/1.1 412 Precondition Failed
Connection: keep-alive
Content-Length: 0
2013-06-07 08:34:08,736 [0x57fd3f0] DEBUG (HttpClient :194 ) - HTTP/1.1 412 Precondition Failed
2013-06-07 08:34:08,738 [0x57fd3f0] DEBUG (HttpClient :194 ) - Connection: keep-alive
2013-06-07 08:34:08,739 [0x57fd3f0] DEBUG (HttpClient :194 ) - Content-Length: 0
2013-06-07 08:34:08,741 [0x57fd3f0] DEBUG (HttpClient :220 ) - status_code:412
2013-06-07 08:34:08,743 [0x57fd3f0] DEBUG (TxHttpControl :299 ) - do_end: HTTP status: 412 resp:
2013-06-07 08:34:08,745 [0x57fd3f0] DEBUG (TxControl :66 ) - end: outcome: -7
{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, 10 months
[JBoss JIRA] (JBTM-1016) Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1016?page=com.atlassian.jira.plugin.... ]
Amos Feng commented on JBTM-1016:
---------------------------------
Paul,
can I delete XTS/localjunit/crash-recovery-tests/check.sh as now we can use maven plugin to check rule ?
> Run bmcheck.sh regularly to spot inconsistencies between byteman scripts and the code
> -------------------------------------------------------------------------------------
>
> Key: JBTM-1016
> URL: https://issues.jboss.org/browse/JBTM-1016
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Paul Robinson
> Assignee: Amos Feng
> Fix For: 5.0.0.M4
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> I've found many bugs in the XTS crash recovery tests that where due to changes being made to the XTS code without updating the byteman scripts. The problem is that these inconsistencies often go unnoticed when the tests run, until you notice a failure in the test.
> Can we run bmcheck as part of the maven build and make the build fail if it detects errors? Needs to be integrated into the poms, perhaps by an exec in an antrun plugin
> NOTE: Before raising the pull req it will be necessary to resolve any the discovered errors.
--
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, 10 months
[JBoss JIRA] (JBTM-1751) TransactionRolledBackException thrown during commit in com.jboss.transaction.txinterop.interop.ATTest
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-1751?page=com.atlassian.jira.plugin.... ]
Amos Feng updated JBTM-1751:
----------------------------
Original Estimate: 2 hours
Remaining Estimate: 2 hours
> TransactionRolledBackException thrown during commit in com.jboss.transaction.txinterop.interop.ATTest
> -----------------------------------------------------------------------------------------------------
>
> Key: JBTM-1751
> URL: https://issues.jboss.org/browse/JBTM-1751
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: XTS
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.0.M4
>
> Original Estimate: 2 hours
> Remaining Estimate: 2 hours
>
> http://172.17.131.2/view/Narayana+BlackTie/job/jbossts-EAP61/1791/console...
> {code}
> [0m[31m22:25:44,948 ERROR [org.jboss.arquillian.protocol.jmx.JMXTestRunner] (pool-1-thread-1) Failed: com.jboss.transaction.txinterop.interop.ATTest.testAT4_1: com.arjuna.wst.TransactionRolledBackException
> at com.arjuna.wst11.stub.CompletionStub.commit(CompletionStub.java:65) [jbossxts-4.17.5.Final-SNAPSHOT.jar:4.17.5.Final-SNAPSHOT]
> at com.jboss.transaction.txinterop.interop.ATTestCase.testAT4_1(ATTestCase.java:281) [classes:]
> at com.jboss.transaction.txinterop.interop.ATTest.testAT4_1(ATTest.java:104) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_37]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) [arquillian-service:]
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [arquillian-service:]
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_37]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) [arquillian-service:]
> at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_37]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source) [:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source) [:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) [arquillian-service:]
> at sun.reflect.GeneratedMethodAccessor87.invoke(Unknown Source) [:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) [arquillian-service:]
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) [arquillian-service:]
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) [arquillian-service:]
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) [arquillian-service:]
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) [arquillian-service:]
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) [arquillian-service:]
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) [arquillian-service:]
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) [arquillian-service:]
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) [arquillian-service:]
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) [arquillian-service:]
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) [arquillian-service:]
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300) [arquillian-service:]
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157) [arquillian-service:]
> at org.junit.runner.JUnitCore.run(JUnitCore.java:136) [arquillian-service:]
> at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethodInternal(JMXTestRunner.java:128) [arquillian-service:]
> at org.jboss.arquillian.protocol.jmx.JMXTestRunner.runTestMethod(JMXTestRunner.java:107) [arquillian-service:]
> at org.jboss.as.arquillian.service.ArquillianService$ExtendedJMXTestRunner.runTestMethod(ArquillianService.java:214) [arquillian-service:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_37]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_37]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_37]
> at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:93) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:27) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:208) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:120) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:262) [rt.jar:1.6.0_37]
> at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:836) [rt.jar:1.6.0_37]
> at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:761) [rt.jar:1.6.0_37]
> at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:527)
> at org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:263)
> at org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:915)
> at org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:152)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_37]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_37]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_37]
> {code}
> Another errors in the log:
> {code}
> [0m[33m22:26:26,763 WARN [com.arjuna.mw.wstx] (TaskWorker-2) ARJUNA045035: comms timeout attempting to prepare WS-AT participant D0:ffffac118324:4acfdb55:51afacb7:87
> [0m[31m22:26:26,763 ERROR [stderr] (TaskWorker-2) com.arjuna.mw.wsas.exceptions.SystemCommunicationException: com.arjuna.wst.stub.SystemCommunicationException
> [0m[31m22:26:26,763 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.prepare(DurableTwoPhaseCommitParticipant.java:124)
> [0m[31m22:26:26,764 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.confirmOnePhase(DurableTwoPhaseCommitParticipant.java:233)
> [0m[31m22:26:26,764 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.ParticipantRecord.topLevelOnePhaseCommit(ParticipantRecord.java:429)
> [0m[31m22:26:26,764 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2263)
> [0m[31m22:26:26,764 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475)
> [0m[31m22:26:26,764 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> [0m[31m22:26:26,765 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.CoordinatorControl.complete(CoordinatorControl.java:137)
> [0m[31m22:26:26,765 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf11.model.twophase.arjunacore.TwoPhaseHLSImple.complete(TwoPhaseHLSImple.java:130)
> [0m[31m22:26:26,765 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wsas.activity.ActivityImple.end(ActivityImple.java:293)
> [0m[31m22:26:26,765 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wsas.UserActivityImple.end(UserActivityImple.java:261)
> [0m[31m22:26:26,765 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.CoordinatorServiceImple.confirm(CoordinatorServiceImple.java:156)
> [0m[31m22:26:26,766 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst11.at.participants.CompletionCoordinatorImple.commit(CompletionCoordinatorImple.java:41)
> [0m[31m22:26:26,766 ERROR [stderr] (TaskWorker-2) at com.arjuna.wst11.messaging.CompletionCoordinatorProcessorImpl.commit(CompletionCoordinatorProcessorImpl.java:84)
> [0m[31m22:26:26,766 ERROR [stderr] (TaskWorker-2) at com.arjuna.webservices11.wsat.sei.CompletionCoordinatorPortTypeImpl$1.executeTask(CompletionCoordinatorPortTypeImpl.java:58)
> [0m[31m22:26:26,766 ERROR [stderr] (TaskWorker-2) at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:63)
> [0m[31m22:26:26,766 ERROR [stderr] (TaskWorker-2) at java.lang.Thread.run(Thread.java:662)
> {code}
> and:
> {code}
> [0m[33m22:27:03,729 WARN [com.arjuna.mw.wstx] (TaskWorker-2) ARJUNA045035: comms timeout attempting to prepare WS-AT participant D0:ffffac118324:4acfdb55:51afacb7:9c
> [0m[31m22:27:03,730 ERROR [stderr] (TaskWorker-2) com.arjuna.mw.wsas.exceptions.SystemCommunicationException: com.arjuna.wst.stub.SystemCommunicationException
> [0m[31m22:27:03,730 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.prepare(DurableTwoPhaseCommitParticipant.java:124)
> [0m[31m22:27:03,731 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst.at.participants.DurableTwoPhaseCommitParticipant.confirmOnePhase(DurableTwoPhaseCommitParticipant.java:233)
> [0m[31m22:27:03,731 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.ParticipantRecord.topLevelOnePhaseCommit(ParticipantRecord.java:429)
> [0m[31m22:27:03,731 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.BasicAction.onePhaseCommit(BasicAction.java:2263)
> [0m[31m22:27:03,731 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.BasicAction.End(BasicAction.java:1475)
> [0m[31m22:27:03,732 ERROR [stderr] (TaskWorker-2) at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:98)
> [0m[31m22:27:03,732 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.CoordinatorControl.complete(CoordinatorControl.java:137)
> [0m[31m22:27:03,732 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf11.model.twophase.arjunacore.TwoPhaseHLSImple.complete(TwoPhaseHLSImple.java:130)
> [0m[31m22:27:03,732 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wsas.activity.ActivityImple.end(ActivityImple.java:293)
> [0m[31m22:27:03,733 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wsas.UserActivityImple.end(UserActivityImple.java:261)
> [0m[31m22:27:03,733 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wscf.model.twophase.arjunacore.CoordinatorServiceImple.confirm(CoordinatorServiceImple.java:156)
> [0m[31m22:27:03,733 ERROR [stderr] (TaskWorker-2) at com.arjuna.mwlabs.wst11.at.participants.CompletionCoordinatorImple.commit(CompletionCoordinatorImple.java:41)
> [0m[31m22:27:03,733 ERROR [stderr] (TaskWorker-2) at com.arjuna.wst11.messaging.CompletionCoordinatorProcessorImpl.commit(CompletionCoordinatorProcessorImpl.java:84)
> [0m[31m22:27:03,733 ERROR [stderr] (TaskWorker-2) at com.arjuna.webservices11.wsat.sei.CompletionCoordinatorPortTypeImpl$1.executeTask(CompletionCoordinatorPortTypeImpl.java:58)
> [0m[31m22:27:03,734 ERROR [stderr] (TaskWorker-2) at com.arjuna.services.framework.task.TaskWorker.run(TaskWorker.java:63)
> [0m[31m22:27:03,734 ERROR [stderr] (TaskWorker-2) at java.lang.Thread.run(Thread.java:662)
> {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, 10 months