You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by an...@uk.bnpparibas.com on 2010/06/15 09:18:53 UTC
design question about temporary queues
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.
Re: design question about temporary queues
Posted by an...@uk.bnpparibas.com.
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, <an...@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, <an...@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.
Re: design question about temporary queues
Posted by Dejan Bosanac <de...@nighttale.net>.
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, <an...@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, <an...@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.
>
Re: design question about temporary queues
Posted by an...@uk.bnpparibas.com.
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, <an...@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.
Re: design question about temporary queues
Posted by Dejan Bosanac <de...@nighttale.net>.
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, <an...@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.
>