activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From andrew.mar...@uk.bnpparibas.com
Subject Re: Temporary queues and a WAN
Date Wed, 23 Jun 2010 07:21:14 GMT
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.tully@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.marlow@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.pechorin@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.marlow@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.

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