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
