Why does a connection for MDB with maxSession=1 has 2 sessions?

[Peter]

Hi Guys,

I'm curious to understand why a connection would have 2 sessions in my circumstance.

I have a single MDB on JBoss EAP 6.1.0 using the generic JMS JCA resource adapter 1.0.0 connecting to Tibco EMS.

The MDB has set the activation property maxSession = 1.

In my Tibco monitoring tool, the client connection is listed as:

ConsumerCount = 1

SessionCount = 2

Also, setting the maxSession to other values, the session count is always 1 greater than activation property maxSession (i.e if maxSesssion=5 from a MDB, SessionCount will be 6).

Other MDB implementations using other implementations (OC4J, Spring) tend (but not always) have 1 consumer and 1 session for each connection.

I am concerned that my application is behaving differently from other implementations 

I think one of the sessions will be the queue listener for a single MDB instance.

But what is the other session doing?

For this resource adapter under these circumstances: 

1. Is this expected behavior?
2. What is the extra session?
   

Thanks in advance, for any guidance.

Regards Peter

[Justin Bertram]

Based on my reading of the code I would expect the actual number of session to equal the value for "maxSession."  Might you have another client that is connecting to that same node? It could even be a producer from the same node hosting the MDB.

[Peter]

Thanks Justin,

Since it doesn't make sense, i'll dig a little further.

Logs on trace not telling me much.

One thing I've found in the Logs is that the Tibco EMS ConnectionFactory has two addresses for its URL.

12:49:07,766 DEBUG [org.jboss.resource.adapter.jms.inflow.JmsActivation] (default-threads - 1) Got connection factory QueueConnectionFactory[URL=tcp://esb1.dev.det.nsw.edu.au:8222,tcp://esb1.dev.det.nsw.edu.au:8222;clientID=null;Properties={com.tibco.tibjms.reconnect.attemptdelay=1000, com.tibco.tibjms.multicast.enabled=true, com.tibco.tibjms.reconnect.attemptcount=30}] from QueueConnectionFactory

They are the same server in the development environment, but in PROD they are esb1 and esb2...

Would that explain the two sessions?

(Although if it does explain it, it doesn't explain why other technologies differ.)

Regards.

[Justin Bertram]

Logs on trace not telling me much.

Unfortunately there's not much logging around the session creation for an MDB.  You might try adding some and rebuilding the RA.  It should be pretty straight-forward to do.  Look at org.jboss.resource.adapter.jms.inflow.JmsServerSessionPool.setupSessions().

One thing I've found in the Logs is that the Tibco EMS ConnectionFactory has two addresses for its URL... 

Would that explain the two sessions?

I don't think that would explain 2 sessions.  From what I understand the Tibco client implementation will select one of the addresses from the URL.

I'm curious if you're seeing any functional impact from the "extra" session.  Is your application working normally?  If not, please elaborate further on the problematic symptoms.  

[Peter]

Thanks again,

> I'm curious if you're seeing any functional impact from the "extra" session.  Is your application working normally?  If not, please elaborate further on the problematic symptoms.  

I dont think so. Appears to be working fine in local testing. 

My main concern is understanding it enough so there are not surprises after deployment and am able to support and troubleshoot.

Having looked at it further in a debugger, the two sessions are created in the following methods:

1. JmsServerSessionPool.setupSessions()

   session.setup();

2. JmsServerSessionPool.setupConsumer()

   consumer = connection.createConnectionConsumer(queue, selector, this, maxMessages);

Looking at the resulting consumer object shows, I think I can see each of the session objects:

consumer (id=763)

_closed false

_connection TibjmsQueueConnection  (id=435)

_consumer TibjmsQueueReceiver  (id=768)

_destination TibjmsFederatedQueue  (id=769)

_durableName null

_lock Object  (id=771)

_max_messages 1

_messages Vector<E>  (id=773)

_pool JmsServerSessionPool  (id=413)

activation JmsActivation  (id=418)

consumer TibjmsConnectionConsumer  (id=763)

serverSessions ArrayList<E>  (id=794)

elementData Object[10]  (id=800)

[0] JmsServerSession  (id=801)

endpoint $Proxy14  (id=803)

pool JmsServerSessionPool  (id=413)

session TibjmsxSessionImp  (id=807)       <---------- Session in pool created by JmsServerSessionPool.setupSessions ->  session.setup();

tm TransactionManagerDelegate  (id=808)

xaSession null

modCount 1

size 1

sessionCount 1

stopped false

_receiver Thread  (id=762)

_selector null

_session TibjmsQueueSession  (id=778)               <---------- Session in consumer object created by JmsServerSessionPool.setupConsumer -> connection.createConnectionConsumer(queue, selector, this, maxMessages);

The method connection.createConnectionConsumer(queue, selector, this, maxMessages) creates TibjmsConnectionConsumer object and is Tibco implemented code so I can't say much about it.

The consumer object appears to have its own session, which is additional to those in the session pool.

Assuming the Tibco method is doing the right thing with that additional session, then otherwise the resource adapter appears to be doing the right thing.

[Justin Bertram]

As you indicated, this looks like an implementation detail of the Tibco client when using a connection consumer.  There's nothing to be done about this from the RA's perspective.