[
https://issues.jboss.org/browse/JBTM-1209?page=com.atlassian.jira.plugin....
]
Amos Feng commented on JBTM-1209:
---------------------------------
I re-checked the output and found the problem is about the following:
1. booting the container at the first time with the xtstest.war which has not been removed
at the prev test.
2. killJVM() happens before the the arquillian call deploy("xtstest.war")
XTS/localjunit/crash-recovery-tests/src/test/java/com/arjuna/qa/junit/BaseCrashTest.java
130 line
controller.start("jboss-as", config.map()); <-- killJVM happens here
deployer.deploy("xtstest"); <-- Test throws exception and fail
3. the test fail and the checkTxObjectStore() return false since there are participants
records in the directory.
so I think it could be a duplicate issue to JBTM-1210.
XTS recovery tests failing due to a non-empty TXObjectStore after
test complete
-------------------------------------------------------------------------------
Key: JBTM-1209
URL:
https://issues.jboss.org/browse/JBTM-1209
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Affects Versions: 5.0.0.M1
Reporter: Paul Robinson
Assignee: Amos Feng
Fix For: 4.17.0, 5.0.0.M2
See:
http://172.17.131.2/view/Narayana+BlackTie/job/narayana-java7/411/console
Looking at
http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-...
you will see:
{code}
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:92)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertTrue(Assert.java:54)
at com.arjuna.qa.junit.BaseCrashTest.tearDown(BaseCrashTest.java:105)
{code}
This assertion checks that the TXObjectStore is empty after the test completes. For the
three tests that failed in this job, the log was not empty.
Looking at the end of
http://172.17.131.2/job/narayana-java7/411/artifact/XTS/localjunit/crash-...
shows you:
{code}
[0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed
state} : removed committed transaction 0:ffffac118303:4e49dd0f:50110ed5:10
[0m[0m10:36:04,605 INFO [stdout] (Periodic Recovery) rule.debug{trace remove committed
state} : !!!killing JVM!!!
{code}
This suggests that the transaction log was removed. However, I'm not sure that the
Byteman script checks that the participant record has also been removed. It's possible
that the AS is being killed slightly too early, before the participant record is removed.
We should check other scripts to see if they wait for both logs to be removed.
[JBTM-1208] should help debug this problem if we get it again.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira