activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject design question about temporary queues
Date Tue, 15 Jun 2010 07:18:53 GMT
I am using AMQ-cpp for a client-server system where my server will be long 
running and in the meantime the queue manager may be restarted. So far in 
my implementation I have been using  one request Q upon which all requests 
are rcvd, and temporary Qs for the replies. When all is well this works 
just fine. However, when the connection to the Q mgr is lost the contents 
of the temporary Qs is lost. I realise this is the way that temporary Qs 
are supposed to work but it makes me wonder if temporary Qs are right for 
a long running server when the Q mgr may go away. What do people think?

The other design I had in mind, which I have seen implemented elsewhere, 
is for the server to have a reply Q and clients use a message selector to 
get the reply for their correlation id. I am not sure I can do that 
because my client will actually be firing off several requests close 
together before getting a reply for any of them. So if I was to browse for 
replies I would have to watch out for all the correlation ids for any 
pending replies.

I am on the verge of writing some recovery code that remembers the 
messages sent for which no reply has been rcvd yet and resends them on a 
reconnect. This is a little bit involved and makes me wonder if maybe I 
shouldn't be using temporary Qs after all. But I heard somewhere that 
temporary Qs are supposed to be the better solution, more scalable, better 
performance etc etc. Can anyone comment please?


Andrew Marlow

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