This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1002538 - ConnectionRequestInfo implementation in generic resource adapter leads to impossibility to get connection in some cases when used with TIBCO EMS 6.3
ConnectionRequestInfo implementation in generic resource adapter leads to imp...
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: JCA, JMS (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ER1
: EAP 6.2.0
Assigned To: Jeff Mesnil
Vladimir Rastseluev
Russell Dickenson
Depends On:
  Show dependency treegraph
Reported: 2013-08-29 08:14 EDT by Vladimir Rastseluev
Modified: 2014-01-12 19:22 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-15 11:48:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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-29 08:14:31 EDT
Description of problem:
During TIBCO EMS certification we use generic resource adapter(
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(
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getSimpleConnection(
        at org.jboss.jca.core.connectionmanager.pool.AbstractPool.getConnection(
        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.getManagedConnection(
        ... 34 more
Caused by: javax.resource.ResourceException: javax.resource.ResourceException: Unable to setup connection
        at org.jboss.resource.adapter.jms.JmsManagedConnection.<init>(
        at org.jboss.resource.adapter.jms.JmsManagedConnectionFactory.createManagedConnection(
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(
        at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.getConnection(
        ... 37 more
Caused by: javax.resource.ResourceException: Unable to setup connection
        at org.jboss.resource.adapter.jms.JmsManagedConnection.setup(
        at org.jboss.resource.adapter.jms.JmsManagedConnection.<init>(
        ... 40 more
Caused by: javax.jms.InvalidClientIDException: clientId already exists
        at com.tibco.tibjms.Tibjmsx.buildException( [tibjms.jar:6.3.0]
        at com.tibco.tibjms.TibjmsConnection.setClientID( [tibjms.jar:6.3.0]
        at org.jboss.resource.adapter.jms.JmsManagedConnection.setup(
        ... 41 more

Failing tests in TCK run job are here:,jdk=java16_default,label=RHEL6/10/testReport/unknownTestSuite.0/packageTests/

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 18:01:27 EDT
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 04:45:48 EDT
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 08:44:18 EDT
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 06:58:27 EDT
the generic-jms-ra has been updated with a fix that removes the clientID from the RA's CRI (see

New master branch for the community project is at
Comment 5 Vladimir Rastseluev 2013-09-13 00:07:17 EDT

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