Ulhas Bhole schrieb:
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).
As far as I know the current way is a pool of temporary queues. So I
guess the performance is quite good. I only do not know how to easily
set this up with Spring JMS.
I also wonder how much performance a pool of temporary queues gives you
compared to one single listening thread on a single temporary queue that
dispatches to a threadpool after it has received the JMS message. My
guess is that the jms receive is quite fast and dispatching to a
threadpool could be almost as fast as having a pool of listeners in the
first place.
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.
My colleague Edaurd also told me that there is a correlation
interceptor. Does this interceptor perhaps already do all we need?
I just remembered that we could have another problem with listener
threads on a permanent reply queue. If we have two machines listening on
the same queue but not with a single Messageselector (as they wait for
several messages) they can not know for which machine a message on the
reply queue is.
Best regards
Christian
--
Christian Schneider
---
http://www.liquid-reality.de
