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.mar...@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 > de...@nighttale.net > Sent by: chubr...@gmail.com > 15/06/2010 09:30 > Please respond to > users@activemq.apache.org > > > To > users@activemq.apache.org > cc > age...@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.mar...@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. >
