Bug 1002538 - ConnectionRequestInfo implementation in generic resource adapter leads to impossibility to get connection in some cases when used with TIBCO EMS 6.3
Summary: ConnectionRequestInfo implementation in generic resource adapter leads to imp...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JCA, JMS
Version: 6.1.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER1
: EAP 6.2.0
Assignee: Jeff Mesnil
QA Contact: Vladimir Rastseluev
Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-29 12:14 UTC by Vladimir Rastseluev
Modified: 2014-01-13 00:22 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-12-15 16:48:44 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Vladimir Rastseluev 2013-08-29 12:14:31 UTC
Description of problem:
During TIBCO EMS certification we use generic resource adapter(https://github.com/jbertram/generic-jms-ra).
ConnectionRequestInfo (CRI) implementation of generic RA needs to be updated to avoid unexpected Exceptions in some cases.
Current CRI implementation includes several fields(userName, password, cliendID, transacted, acknowledgeMode, type). 
In EAP PoolByCri pool implementation is used to keep active connections. This pool is divided on subpools due to CRI, used in ManagedConnection(MC) creation. That means, that if we use different user name or password or any of mentioned above parameters in CRI - there will be a new subpool created to keep such connections.

In TCK run we use the same topic connection factory both for transactional and non-transactional tests. This connection factory has a clientID.

For example, we use it in non-transactional test, create ManagedConnection (in CRI transacted=false), set this clientID to connection and after test this MC is returned to the connections subpool.

When we try to get ManagedConnection for the transactional test, due to CRI implementation, there will be another subpool created (transacted=true). Hense we don't use MC, saved in previous subpool, but create a new one.  When we try to set clientId to this new connection we'll get ResourceException with cause:
IJ000658: Unexpected throwable while trying to create a connection: null
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:377)
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(AbstractPool.java:397)
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(AbstractPool.java:365)
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(AbstractConnectionManager.java:329)
        ... 34 more
Caused by: javax.resource.ResourceException: javax.resource.ResourceException: Unable to setup connection
        at org.jboss.resource.adapter.jms.JmsManagedConnection.<init>(JmsManagedConnection.java:191)
        at org.jboss.resource.adapter.jms.JmsManagedConnectionFactory.createManagedConnection(JmsManagedConnectionFactory.java:104)
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:781)
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(SemaphoreArrayListManagedConnectionPool.java:344)
        ... 37 more
Caused by: javax.resource.ResourceException: Unable to setup connection
        at org.jboss.resource.adapter.jms.JmsManagedConnection.setup(JmsManagedConnection.java:691)
        at org.jboss.resource.adapter.jms.JmsManagedConnection.<init>(JmsManagedConnection.java:185)
        ... 40 more
Caused by: javax.jms.InvalidClientIDException: clientId already exists
        at com.tibco.tibjms.Tibjmsx.buildException(Tibjmsx.java:586) [tibjms.jar:6.3.0]
        at com.tibco.tibjms.TibjmsConnection.setClientID(TibjmsConnection.java:4363) [tibjms.jar:6.3.0]
        at org.jboss.resource.adapter.jms.JmsManagedConnection.setup(JmsManagedConnection.java:651)
        ... 41 more


Failing tests in TCK run job are here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-TIBCO-EMS/job/tibco-ems-EAP6.x-tck6-jms-matrix/MODULE=all,jdk=java16_default,label=RHEL6/10/testReport/unknownTestSuite.0/packageTests/com.sun.ts.tests.jms.ee.all.closedtopicsessiontests/

I think, this bug can be reproduceable by changing any of CRI parameters, e.g. acknowledgeMode.

Version-Release number of selected component (if applicable):
EAP 6.1.1 ER7

Comment 1 Justin Bertram 2013-08-29 22:01:27 UTC
This an all future bugs for this project should be assigned to Jeff Mesnil as he has been identified as the owner in engineering.

Comment 2 Jeff Mesnil 2013-09-03 08:45:48 UTC
If I understand the issue correctly, 

when the transaction test is run, we have a different CRI (transacted=true) and we must create a new managed connection.
Is that correct?

In JmsManagedConnection.setup, we lookup the CF and create a new (TIBCO) JMS connection.
The issue is that this new connection already has a clientID.
Does TIBCO provide a pooled connection factory that reuse existing JMS connections?

Comment 3 Vladimir Rastseluev 2013-09-03 12:44:18 UTC
Yes, you understand correctly the first part - we really need to create different managed connections for transacted and non-transacted CRI.

But the problem IMO is that connection, returned to pool contains clientID.
When we create a new connection, after lookup, we try to set clientID to it.

As described javax.jms.Connection interface: If another connection with the same clientID is already running when setClientId() method is called, the JMS provider should detect the duplicate ID and throw an InvalidClientIDException.

So this happens here.

I don't know, if TIBCO uses pooled connection factory or not.

Comment 4 Jeff Mesnil 2013-09-09 10:58:27 UTC
the generic-jms-ra has been updated with a fix that removes the clientID from the RA's CRI (see https://github.com/jms-ra/generic-jms-ra/issues/1)

New master branch for the community project is at https://github.com/jms-ra/generic-jms-ra

Comment 5 Vladimir Rastseluev 2013-09-13 04:07:17 UTC
Verified


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