activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: design question about temporary queues
Date Wed, 16 Jun 2010 08:37:43 GMT
I am also looking into using an exception listener. It looks to me like 
this should work on the server side.


Andrew Marlow

Sent by:
16/06/2010 08:52
Please respond to


Re: design question about temporary queues

Hi Andrew,

if you want that your requests/replies survive broker crash, you can 
the same solution, only using regular queues and persistent messages.

Dejan Bosanac -

On Tue, Jun 15, 2010 at 11:58 AM, <> wrote:

> Yes thanks. It was on that web page I found this:
> The best way to implement request-response over JMS is to create a
> temporary queue and consumer per client on startup, set JMSReplyTo
> property on each message to the temporary queue and then use a
> correlationID on each message to correlate request messages to response
> messages. This avoids the overhead of creating and closing a consumer 
> each request (which is expensive). It also means you can share the same
> producer & consumer across many threads if you want (or pool them 
> This is exactly what I do. But I wonder if temporary Qs are right for a
> long running server when the Q mgr may go away. And I am not sure how my
> server is supppsed to detect when the Q mgr has gone away.
> Regards,
> Andrew Marlow

> 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 
> correlate them to the originating requests using this id.
> Hope this helps.
> Cheers
> --
> Dejan Bosanac -

> On Tue, Jun 15, 2010 at 9:18 AM, <> 
> > 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 
> > 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 
> > 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 
> >
> > The other design I had in mind, which I have seen implemented 
> > 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 
> > reconnect. This is a little bit involved and makes me wonder if maybe 
> > 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