activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dejan Bosanac <de...@nighttale.net>
Subject Re: design question about temporary queues
Date Wed, 16 Jun 2010 07:52:23 GMT
Hi Andrew,

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

Cheers
--
Dejan Bosanac - http://twitter.com/dejanb

Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net


On Tue, Jun 15, 2010 at 11:58 AM, <andrew.marlow@uk.bnpparibas.com> 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 for
> each request (which is expensive). It also means you can share the same
> producer & consumer across many threads if you want (or pool them maybe).
>
> 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
>
>
>
>
> Internet
> dejan@nighttale.net
> Sent by: chubrilo@gmail.com
> 15/06/2010 09:30
> Please respond to
> users@activemq.apache.org
>
>
> To
> users@activemq.apache.org
> cc
> agents@andrewpetermarlow.co.uk
> Subject
> Re: design question about temporary queues
>
>
>
>
>
>
> Hi Andrew,
>
> I guess you looked at
>
> http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html
>
>
> 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.
>
> Cheers
> --
> Dejan Bosanac - http://twitter.com/dejanb
>
> Open Source Integration - http://fusesource.com/
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
> On Tue, Jun 15, 2010 at 9:18 AM, <andrew.marlow@uk.bnpparibas.com> 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
> >
>
> http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H
> for additional disclosures.
> >
>
>
> ___________________________________________________________
> 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
> http://www.bnpparibas.co.uk/en/information/legal_information.asp?Code=ECAS-845C5H for
additional disclosures.
>

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