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:
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.
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
feedback).
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
