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