I think that jms:temp:queue sounds like a bug as I have no idea how this
could work.
Creating temp queues works in this way in the jms api:
Destination tempDest = session.createTemporaryQueue();
So I think there is no way to tell the jms server the name of the queue.
The following article could be intersting for you:
http://tim.oreilly.com/pub/a/onjava/2007/04/10/designing-messaging-applications-with-temporary-queues.html
You could also try to use one queue and use message selectors to only
get certain messages. I have no idea how well this performs though.
Other than that I think dynamic queues are your only option. At least
with camel.
What I don´t understand in your case is under which circumstances a new
temp queue would be created and when it would be destroyed. Does the
receiver know how many responses to expect and can then destroy the temp
queue again?
Btw. there is another problem with temp queues. If your jms server goes
down for too long all connections will be closed and all temp queues
too. So when the jms server comes back and the clients do an automatic
reconnect then there will be stale temp queues that can not be used
anymore. So I think in general a temp queue should not be used as a long
term channel that you want to rely on.
Christian
Am 16.03.2011 13:32, schrieb enalposi:
Thanks Christian -
In a nutshell and simplified view, ignoring threads etc, what we need is
similar to request/response but keeping the temp response channel open as
long as we wish, to send several messages. In fact I don't understand the
purpose of a Camel Temp queue if different parties don't create the same
concrete temp JMS queue for the same temp Camel destination
(jms:temp:queue:). That would mean one cannot have different nodes
communicate on temp queues - is this a bug?
Dynamic queues with their associated life cycle aren't an option for us.
Cheers!
--
View this message in context:
http://camel.465427.n5.nabble.com/Issue-with-JMS-Temp-Queues-Tibco-EMS-tp3425694p3779605.html
Sent from the Camel - Users mailing list archive at Nabble.com.
--
----
http://www.liquid-reality.de
