Thanks for those clarifying comments. The answer is "yes, I can afford to lose a reply.". There comes a point where the client will give up and then it does not matter if the server completes the work or not. The work done by the server is idempotent. So it does not matter if it is asked to do it again during a reconnect.
Regards, Andrew Marlow Internet gary.tu...@gmail.com 22/06/2010 17:40 Please respond to users@activemq.apache.org To users@activemq.apache.org cc Subject Re: Temporary queues and a WAN The choice of tempQ vs replyQ comes down to the need for a durable reply which can help with idempotency. In the case of a tempq and your rcvd table (the failover transport has just such a table internally btw), on the resend there will be no indication of a potential previous reply as the tempQ will have been destroyed and been recreated. With a replyQ, it is possible to determine if a reply already exists because any reply will have been persisted. So it comes down to the question: can you loose a reply? If you can't loose a reply and you need scalability, using a pool of reply queues and some discriminator to choose a q may be a suitable pattern. On 22 June 2010 16:43, <andrew.mar...@uk.bnpparibas.com> wrote: > I am aware of the fact that when using temp Qs the data goes away when the > connection is lost. I cope with this with some extra logic on the client > side. It remembers each request via a table. Entries are removed from this > table when replies are rcvd. When the connection is lost a reconnect is > done and the table is then used to resend any requests for which the reply > was pending. > > I am still puzzled as to what the received wisdom is regarding the use of > temporary queues. Are they of no practical use? I get around the problem > of lost connections as per the above. And I do this because I thought that > temporary Qs are to be preferred to a reply Q for scalability reasons. I > am not so sure now.... I note that a reply Q is a very common way of doing > client-server request-response despite the advice from the ActiveMQ web > page. Hmmmm. > > Regards, > > Andrew Marlow > > > > > Internet > ivan.pecho...@gmail.com > 22/06/2010 16:23 > Please respond to > users@activemq.apache.org > > > To > users@activemq.apache.org > cc > > Subject > Re: Temporary queues and a WAN > > > > > > > 2010/6/22 <andrew.mar...@uk.bnpparibas.com>: > > As per the advice at > > > > http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html > > > I am using temporary Qs for my replies. > > ... > > > > Because of various technical obstacles that I wont go into here, I am > only > > able to run with ActiveMQ locally. ActiveMQ is fine there and so is > > IBM-MQSeries. I am not able to see if ActiveMQ would still work in the > WAN > > situation. But IBM does not seem to like it. What advice/recommendations > > do people have please? > > As far as I understand, temporary queues in ActiveMQ are directly > linked to client connection. > If client connection to broker is interrupted, all the temporary > queues created within this connection are lost. > If there were any requests in the middle of processing, replies to > these requests are lost (because ReplyTo destination specified in > these requests is no longer valid). > The same problem remains in case if client uses failover transport. > That's why we don't use temporary queues for ReplyTo. > > ActiveMQ gurus, please correct me, if I am wrong. > Actually, I didn't perform enough testing to be 100% sure of the > statements above. > > > ___________________________________________________________ > 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. > -- http://blog.garytully.com Open Source Integration http://fusesource.com ___________________________________________________________ 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.
