activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Tully <>
Subject Re: Temporary queues and a WAN
Date Tue, 22 Jun 2010 16:40:04 GMT
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, <> 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
> 22/06/2010 16:23
> Please respond to
> To
> cc
> Subject
> Re: Temporary queues and a WAN
> 2010/6/22  <>:
> > As per the advice at
> >
> > 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
> > 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
> for
additional disclosures.


Open Source Integration

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message