Bug 1002538

Summary:	ConnectionRequestInfo implementation in generic resource adapter leads to impossibility to get connection in some cases when used with TIBCO EMS 6.3
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Vladimir Rastseluev <vrastsel>
Component:	JCA, JMS	Assignee:	Jeff Mesnil <jmesnil>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Vladimir Rastseluev <vrastsel>
Severity:	unspecified	Docs Contact:	Russell Dickenson <rdickens>
Priority:	unspecified
Version:	6.1.1	CC:	jbertram, jpederse, pslavice
Target Milestone:	ER1
Target Release:	EAP 6.2.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-15 16:48:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

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