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 de...@nighttale.net Sent by: chubr...@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.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 > 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.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.
