Bug 787149 - TCK: A subset of ejbweb test fails due to exclusive locking
Summary: TCK: A subset of ejbweb test fails due to exclusive locking
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java
Version: Development
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ---
: ---
Assignee: Weston M. Price
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-03 10:39 UTC by Jiri Pechanec
Modified: 2016-02-22 00:59 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Cause: Use of Qpid/MRG JCA adapter with Bean Managed Transactions and incorrect resource usage results in a ResourceLocked exception on C++ Broker. Consequence: When attempting any action on a JMS connection, session, producer or consumer outside of the original JTA transaction a ResourceLocked Exception is thrown. Fix: All activity on a JMS connection, session, producer and consumer must occur within the context of the original XA transaction. Result: The ResourceLocked exception is not thrown and code exhibits known and consistent behavior.
Clone Of:
Environment:
Last Closed: 2013-03-12 12:43:26 UTC
Target Upstream Version:


Attachments (Terms of Use)
Log files related to Test05 (65.08 KB, application/x-gzip)
2012-02-15 06:34 UTC, Jiri Pechanec
no flags Details
Broker trace during durable unsubscribe failure (507.22 KB, application/octet-stream)
2012-02-15 22:31 UTC, Weston M. Price
no flags Details

Description Jiri Pechanec 2012-02-03 10:39:59 UTC
The tests below are all failing

com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test05_from_ejb
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test05_from_jsp
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test05_from_servlet
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test06_from_ejb
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test06_from_jsp
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test06_from_servlet
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test07_from_ejb
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test07_from_jsp
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test07_from_servlet
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test08_from_ejb
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test08_from_jsp
com/sun/ts/tests/jms/ee/ejbweb/xa/TransactionTests.java#Test08_from_servlet

The logs contains messages like
org.apache.qpid.client.JMSAMQException: The queue deletion failed: ch=2 id=1 ExecutionException(errorCode=RESOURCE_LOCKED, commandId=2, classCode=8, commandCode=2, fieldIndex=0, description=resource-locked: Cannot delete queue client_id:Test05; it is exclusive to another session (qpid/broker/SessionAdapter.cpp:349), errorInfo={})

The same behaviour is present even after server restart and execution in isolation.

Comment 1 Weston M. Price 2012-02-09 15:24:46 UTC
Quickly looking at this issue, this may be an misconfiguration. If your using topics, which the test seems to suggest, the session count needs to be set to 1 being that the client_id and subscription name needs to be unique.

Could someone from QE point me to the config that you are using until I can try and re-produce this with my local TCK instance?

Comment 2 Jiri Pechanec 2012-02-14 16:37:37 UTC
All are topics with durable subscriptions

Could it relate to https://issues.apache.org/jira/browse/QPID-2881 ?

Comment 3 Weston M. Price 2012-02-14 19:13:14 UTC
If you don't mind, could you just run this specific test and attach all the necessary log files? 

Thanks.

Comment 4 Rajith Attapattu 2012-02-14 20:52:20 UTC
Jiri,

QPID-2881 is a completely different issue. That was due to two subscribers
trying to use the same queue for subscription.

The issue here, is trying to delete a private queue from a session that didn't
create it. "Cannot delete queue client_id:Test05; it is exclusive to another
session"

Rajith

Comment 5 Jiri Pechanec 2012-02-15 06:34:22 UTC
Created attachment 562132 [details]
Log files related to Test05

I am sorry, I did not notice that I forgot to attach log files. I have executed Test05 only - in isolation. As you can see the issue happens during unsubscribe call.

Comment 6 Jiri Pechanec 2012-02-15 07:09:57 UTC
As you can see from the test, the subscription is created on the client so for Test05 it is created once and only once. The test for first vehicle (EJB) fails due to unsubcribe issue, the following fails (JSP, servlet) because the subscription already exists - was not removed in EJB vehicle.

Comment 7 Jiri Pechanec 2012-02-15 08:15:20 UTC
I tried to move the unsubcribe all around the Test5 method and it works until the first commit is called. If it is placed after tPublisher.publish(msg); then it succeeds but if placed after the ut.commit(); then it fails with the mentioned exception.

Comment 8 Weston M. Price 2012-02-15 22:30:34 UTC
In doing research, this appears to be an issue on the broker side where the broker ties ownership of the queue to an XA transaction versus the session that created the subscriber. I am attaching a broker trace. Also, I have a reproducer that does not require the TCK to re-produce the issue. 

Note, this is not an error in the JCA adapter, however, use of XA which is almost exclusive to JCA at this point causes the issue. Also, when XA is turned off (which the reproducer allows) the code functions as expected.

Comment 9 Weston M. Price 2012-02-15 22:31:46 UTC
Created attachment 562350 [details]
Broker trace during durable unsubscribe failure

Comment 11 Weston M. Price 2012-03-13 19:23:44 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: Use of Qpid/MRG JCA adapter with Bean Managed Transactions and incorrect resource usage results in a ResourceLocked exception on C++ Broker.

Consequence: When attempting any action on a JMS connection, session, producer or consumer outside of the original JTA transaction a ResourceLocked Exception is thrown.

Fix: All activity on a JMS connection, session, producer and consumer must occur within the context of the original XA transaction.

Result: The ResourceLocked exception is not thrown and code exhibits known and consistent behavior.

Comment 12 Gordon Sim 2012-04-24 16:43:00 UTC
(In reply to comment #8)
> In doing research, this appears to be an issue on the broker side where the
> broker ties ownership of the queue to an XA transaction versus the session that
> created the subscriber.

I believe this to be incorrect. The broker trace shows that the session attempting to delete the queue is indeed different from the one that declared it. The exception is therefore expected based on clients actions (i.e. attempt to delete a queue that is exclusive to another session).

> Note, this is not an error in the JCA adapter, however, use of XA which is
> almost exclusive to JCA at this point causes the issue. Also, when XA is turned
> off (which the reproducer allows) the code functions as expected.

I believe this is either a JCA or JMS client issue, not a broker issue.

Comment 13 Weston M. Price 2013-03-12 12:43:26 UTC
Old bug which I believed has been addressed in a subsequent release. As a result, I am closing this.


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