Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of gary.tully@gmail.com designates
 209.85.160.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=O9DKuh5fzrGQ9tNvDp6aFqcimTMZ1t3Mob3ZQrg95SnS+0tY5l0x8AIooQik6CkWAd
         +PTr0nfeLs2ceAjWZXDTfThi0G859eGsNn9IZzgSLMq5SF2k3WFSezQCMTPii+3IzKhP
         gy4WM3NFG8fqLCsvh9CIFICI8wdWZub9nAuNI=
MIME-Version: 1.0
In-Reply-To: 
 <OF03C1AEB5.8C3A3133-ON8025774A.005603B1-8025774A.00566C35@bnpparibas.com>
References: <AANLkTimFchIr6jyJMuzkPVMGsjHH0KAKu_7tddIjU28E@mail.gmail.com>
	<OF03C1AEB5.8C3A3133-ON8025774A.005603B1-8025774A.00566C35@bnpparibas.com>
Date: Tue, 22 Jun 2010 17:40:04 +0100
Message-ID: <AANLkTilnCMxmJOsn-jzD7u8Gj6GuKjR9GDogJSKjTfum@mail.gmail.com>
Subject: Re: Temporary queues and a WAN
From: Gary Tully <gary.tully@gmail.com>
To: users@activemq.apache.org
Content-Type: multipart/alternative; boundary=000e0cd76242c421860489a1129d

--000e0cd76242c421860489a1129d
Content-Type: text/plain; charset=ISO-8859-1

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

--000e0cd76242c421860489a1129d--