cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Question about JMS Session Pool
Date Wed, 03 Sep 2008 19:37:44 GMT
Guillaume Nodet schrieb:
> Commons-pool is not a JMS connection pool.
> I was mostly thinking about the ActiveMQ one, but i think each JMS
> provider should have its own connection pool.  In a Java EE
> environment, the connection pool is done by the server and you don't
> have to think about it.  Anyway, it's part of the ConnectionFactory
> set up by the user, so the CXF code should not really take care of it.
I think you are right that CXF should not take care of it. But in case 
the user does not run the application in an appserver
he will need a connection pool that he can configure as a wrapper on his 
ConnectionFactory. I guess the ActiveMQ pooling is not useable for other 

The Spring CachingConnectionFactory is described here:

In the second link they detail that for a JMStemplate in a standalone 
environment the SingleConnectionFactory should be used to avoid opening 
a connection on every
call to the template.

Currently the JMSConduit works in the following way.
It fetches a PooledSession from the SessionFactory. The PooledSession 
contains already initialized Session, MessageProducer and 
MessageConsumer. If the reply queue is temporary each pooled session has 
a different already created temporary Queue that is reused each time the 
PooledSession is fetched.
Then it sends out a message to the targetDestination and sets the 
replyDestination from the pooledSession as replyTo.
After that it waits synchronously with a consumer on the 
replyDestination for the reply to come.

I think this behaviour is not implemented in any of the Connection Pools 
I know.
So my question here is how would we implement this with a JMSTemplate. 
Without any further configuration the JMSTemplate even with 
SingleConnectionFactory would create a new Session, Producer, Temporary 
Queue and Consumer for each message. I am not sure if this is acceptable.

One idea I have is to Simply create one or more listenerthreads with 
consumers on the replyDestination. They would then receive the responses 
completely asynchronous and we could find the right exchange by using 
the correlationId. One issue with this idea is that we can only have one 
Thread on a temporary queue as the queue is only visible to the Session 
that created the queue. (At least I think so). Any ideas for this?

Best regards



Christian Schneider

View raw message