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:
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/jms/connection/CachingConnectionFactory.html
http://static.springframework.org/spring/docs/2.5.x/reference/jms.html#jms-connections
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
--
Christian Schneider
---
http://www.liquid-reality.de
