Bug 993077 - TIBCO generic jms ra - acknowledgment is not propagated for non-transactional session
TIBCO generic jms ra - acknowledgment is not propagated for non-transactional...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JCA, JMS (Show other bugs)
6.1.1
Unspecified Unspecified
unspecified Severity high
: ---
: ---
Assigned To: Jeff Mesnil
Ondrej Chaloupka
Russell Dickenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-05 11:05 EDT by Vladimir Rastseluev
Modified: 2014-01-12 19:22 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-15 11:22:24 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vladimir Rastseluev 2013-08-05 11:05:27 EDT
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.
Comment 1 Justin Bertram 2013-08-08 10:44:57 EDT
Can you attach the code for this test?  It sounds to me like something is wrong with the test itself.
Comment 2 Vladimir Rastseluev 2013-08-26 05:06:57 EDT
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.
Comment 3 Jeff Mesnil 2013-09-16 04:23:38 EDT
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?
Comment 4 Vladimir Rastseluev 2013-09-20 07:53:16 EDT
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/
Comment 5 Vladimir Rastseluev 2013-09-23 05:21:36 EDT
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
Comment 6 Ondrej Chaloupka 2013-09-26 09:07:17 EDT
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.
Comment 9 Ondrej Chaloupka 2013-10-25 06:56:38 EDT
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
Comment 10 Vladimir Rastseluev 2013-10-30 03:58:25 EDT
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;
Comment 11 Miroslav Novak 2013-11-11 05:52:40 EST
Hi Jeff,

are you still working on generic JMS RA, please?

Thanks,

Mirek
Comment 13 Ondrej Chaloupka 2013-11-20 10:35:57 EST
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?
Comment 14 Jeff Mesnil 2013-11-21 05:13:46 EST
the commit that fixed this issue is https://github.com/jms-ra/generic-jms-ra/commit/b2d96fe15168d07c2debb2c23c42b93de1aec4ea
Comment 15 Ondrej Chaloupka 2013-11-21 05:17:18 EST
Functionality is confirmed to be fixed. Tested on 6.2.0.CR2.

Note You need to log in before you can comment on or make changes to this bug.