Description of problem: JMS crash recovery test "prepareHalt" fails on EAP 6.1.1 ER4 when generic resource adapter + TIBCO EMS 6.3 is used. Version-Release number of selected component (if applicable): EAP 6.1.1 ER4 https://github.com/jbertram/generic-jms-ra How reproducible: easy Steps to Reproduce: see Jenkins job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-TIBCO-EMS/job/eap-60-jbossts-crashrec-tests-ems-tibco/6/ Actual results: test prepareHalt failed Expected results: all tests passed Additional info: The "prepareHalt" test passes, if it's executed as one-test, but fails in test suite run. In job, mentioned above it runs between 2 other tests: "none" and "commitHalt", which both passes. There is a description how tests behave(checked locally on my PC): 1) "none" test just send message in transaction, then checks if message is in output queue; 2) "prepareHalt" test prepares message to send in transaction, then on prepare phase of transaction server is killed. After server restart is expected that message is rolled back. It is, but there is another message from first "none" test remained in output queue. It's odd, but test is able to read this message at the beginning, in clearance phase and at the end, when checks, if something remains in output queue. Test fails on this check. 3) "commitHalt" test sends message end kills server in commit phase of transaction. After server restart message is expected to be delivered to the output queue. This test passes, but at the beginning it also is able to read message from "none" test from output queue.
Can you attach the code for this test? It sounds to me like something is wrong with the test itself.
Test could be found in git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-transactions.git repository in "vrastsel" branch. It doesn't make sense to attach test code here, because it uses parent class and testsuite utilities functionality. Similar tests are there for testing HornetQ and Websphere MQ. You can find server setup steps in Jenkins job, mentioned in issue description.
What's the status of this bug? I see that the upstream jms-ra has a commit about it (https://github.com/jms-ra/generic-jms-ra/commit/6baa2bb8a230b30cab3e5df68fc50184615e9d99). Has the bug been verified with this commit? Is the issue still present?
Yes, it is. Results for EAP 6.2 ER1 will be available soon here: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-60-jbossts-crashrec-tests-jms-tibco-jdk-matrix/
There are results for EAP 6.2.0 ER1 https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-60-jbossts-crashrec-tests-jms-tibco-jdk-matrix/3475/ precisely related results are for jdk=java16_default Anohter jdk's failures also related to https://bugzilla.redhat.com/show_bug.cgi?id=991389
Hi Jeff, the issue is still present and it seems that it's not directly caused by crash recovery failure. The problem why the crash recovery tests fails is the message checking process that does not work for TIBCO messaging. It seems that TIBCO has problem to get acknowledge in case of not transactional session. When you send message to broker from @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) bean and you tries to read it afterwards. You'll get the sent message and in the following read you'll get null (nothing). But the broker does not delete that message from the queue. It is still present. And when you restart server you'll start with receiving messages once again from start.
I've changed the title of the bug as this is not a problem of crash recovery - it just influences the crash recovery testing. The core of the problem is in not propagated acknowledgment to the TIBCO server when non-transactional session is used. Check the comment: https://bugzilla.redhat.com/show_bug.cgi?id=993077#c6
There is wrong code in org.jboss.resource.adapter.jms.JmsManagedConnection, L642. It doesn't make sense what acknowledge mode is passed as a parameter. AUTO_ACKNOWLEDGE mode will be always set in connection. Probably, fix looks like this: int ack = = info.getAcknowledgeMode() != 0? info.getAcknowledgeMode():Session.AUTO_ACKNOWLEDGE;
Hi Jeff, are you still working on generic JMS RA, please? Thanks, Mirek
I've tested the issue with current EAP 6.2.0.CR2 release and it seems that the issue disappeared. From my point of view I could say that this was fixed somehow. Jeff, do you have some idea which commit causes so?
the commit that fixed this issue is https://github.com/jms-ra/generic-jms-ra/commit/b2d96fe15168d07c2debb2c23c42b93de1aec4ea
Functionality is confirmed to be fixed. Tested on 6.2.0.CR2.