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.
