In the current release the session pool should create a number of
replyTo queues that is as high as the high watermark.
Though I think it is possible that this does not work correctly. I am
just working on a new implementation that uses
the spring JMSTemplate for sending / receiving. So this implementation
will initially create and destroy the queue for each request.
I am thinking about an implementation that simply opens up only one
replyTo queue and has one or more permanent listeners
on this queue. Then when the replies arrive the will be correlated to
their requests. I think this will be much less resource consuming.
Greetings
Christian
rgavlin schrieb:
My request/response cxf 2.0.7 client w/JMS transport seems to allocate a
temporary replyTo queue for each request.
Are these temporary queues ever re-used or cleaned-up?
I tried setting the jms-conduit sessionPool low/high waterMarks to "4" and
"8" respectively to control session usage but this did not seem to impact
the temporary replyTo queue allocation.
Please explain briefly how this is supposed to work?
--
Christian Schneider
---
http://www.liquid-reality.de