cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulhas Bhole <>
Subject Re: Question about JMS Session Pool
Date Wed, 03 Sep 2008 21:22:42 GMT
Hi Christian,

comments inline...

-- Ulhas

Christian Schneider wrote:
> 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 providers?
> 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.
I think we should get away from creating temporary queue each time. I 
think it is acceptable to have one temp queue serving as 
replyDestination if no replyDestination is explicitly set. The default 
behavior CXF states should be like " JMS transport will use temporary 
queue if no replyDestination is specified" which can be implemented as 
one temporary queue or pool of temporary queues (with listener for each) 
or the current way (which is highly discouraged as far as I got the 
> 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?
Currently, for request/reponse MEP we set JMSMessageID as correlationID 
so it should not be difficult to implement the correlate response (we 
can maintain hashmap or some collection which would hold the Request 
Exchange keyed using JMSMessageID when the message is sent however,
I think we will need to look into what will happen to the JAX-WS request 
and response context which when last I knew were thread local becuse we 
pump in JMS_REPONSE_HEADERS into it.
> Best regards
> Christian

IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland

View raw message