activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Temporary queues and a WAN
Date Tue, 22 Jun 2010 15:43:56 GMT
I am aware of the fact that when using temp Qs the data goes away when the 
connection is lost. I cope with this with some extra logic on the client 
side. It remembers each request via a table. Entries are removed from this 
table when replies are rcvd. When the connection is lost a reconnect is 
done and the table is then used to resend any requests for which the reply 
was pending.

I am still puzzled as to what the received wisdom is regarding the use of 
temporary queues. Are they of no practical use? I get around the problem 
of lost connections as per the above. And I do this because I thought that 
temporary Qs are to be preferred to a reply Q for scalability reasons. I 
am not so sure now.... I note that a reply Q is a very common way of doing 
client-server request-response despite the advice from the ActiveMQ web 
page. Hmmmm.


Andrew Marlow

22/06/2010 16:23
Please respond to


Re: Temporary queues and a WAN

2010/6/22  <>:
> As per the advice at

> I am using temporary Qs for my replies.
> ...
> Because of various technical obstacles that I wont go into here, I am 
> able to run with ActiveMQ locally. ActiveMQ is fine there and so is
> IBM-MQSeries. I am not able to see if ActiveMQ would still work in the 
> situation. But IBM does not seem to like it. What advice/recommendations
> do people have please?

As far as I understand, temporary queues in ActiveMQ are directly
linked to client connection.
If client connection to broker is interrupted, all the temporary
queues created within this connection are lost.
If there were any requests in the middle of processing, replies to
these requests are lost (because ReplyTo destination specified in
these requests is no longer valid).
The same problem remains in case if client uses failover transport.
That's why we don't use temporary queues for ReplyTo.

ActiveMQ gurus, please correct me, if I am wrong.
Actually, I didn't perform enough testing to be 100% sure of the
statements above.

This e-mail may contain confidential and/or privileged information. If you are not the intended
recipient (or have received this e-mail in error) please notify the sender immediately and
delete this e-mail. Any unauthorised copying, disclosure or distribution of the material in
this e-mail is prohibited.

Please refer to
 for additional disclosures.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message