activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <>
Subject Re: design question about temporary queues
Date Tue, 15 Jun 2010 08:30:38 GMT
Hi Andrew,

I guess you looked at

You can do the thing with correlationId but using normal queues and
persistent messages if your requirement is not to lose any replies. In that
case you don't use selectors, but your consumers take all replies and just
correlate them to the originating requests using this id.

Hope this helps.

Dejan Bosanac -

Open Source Integration -
ActiveMQ in Action -
Blog -

On Tue, Jun 15, 2010 at 9:18 AM, <> wrote:

> 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?
> Regards,
> 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