activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From andrew.mar...@uk.bnpparibas.com
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.

Regards,

Andrew Marlow




Internet 
dejan@nighttale.net
Sent by: chubrilo@gmail.com
16/06/2010 08:52
Please respond to
users@activemq.apache.org


To
users@activemq.apache.org
cc

Subject
Re: design question about temporary queues






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

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

> 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

> 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.

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