Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of
 andrew.marlow@uk.bnpparibas.com designates 155.140.122.252 as permitted
 sender)
In-Reply-To: <AANLkTikr-wx1N-oIaUEMSe0uSEIhicCKZSvIAKXDUKGF@mail.gmail.com>
To: users@activemq.apache.org
Subject: Re: design question about temporary queues
MIME-Version: 1.0
From: andrew.marlow@uk.bnpparibas.com
Message-ID: 
 <OFAF3F1637.C21B322F-ON80257743.00368022-80257743.0036C783@bnpparibas.com>
Date: Tue, 15 Jun 2010 10:58:01 +0100
Content-Type: multipart/alternative;
 boundary="=_alternative 0036C78380257743_="

--=_alternative 0036C78380257743_=
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"

Yes thanks. It was on that web page I found this:

The best way to implement request-response over JMS is to create a 
temporary queue and consumer per client on startup, set JMSReplyTo 
property on each message to the temporary queue and then use a 
correlationID on each message to correlate request messages to response 
messages. This avoids the overhead of creating and closing a consumer for 
each request (which is expensive). It also means you can share the same 
producer & consumer across many threads if you want (or pool them maybe). 

This is exactly what I do. But I wonder if temporary Qs are right for a 
long running server when the Q mgr may go away. And I am not sure how my 
server is supppsed to detect when the Q mgr has gone away.

Regards,

Andrew Marlow


Internet 
dejan@nighttale.net
Sent by: chubrilo@gmail.com
15/06/2010 09:30
Please respond to
users@activemq.apache.org


To
users@activemq.apache.org
cc
agents@andrewpetermarlow.co.uk
Subject
Re: design question about temporary queues


Hi Andrew,

I guess you looked at
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html


You can do the thing with correlationId but using normal queues and
persistent messages if your requirement is not to lose any replies. In 
that
case you don't use selectors, but your consumers take all replies and just
correlate them to the originating requests using this id.

Hope this helps.

Cheers
--
Dejan Bosanac - http://twitter.com/dejanb

Open Source Integration - http://fusesource.com/
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net


On Tue, Jun 15, 2010 at 9:18 AM, <andrew.marlow@uk.bnpparibas.com> wrote:

> I am using AMQ-cpp for a client-server system where my server will be 
long
> running and in the meantime the queue manager may be restarted. So far 
in
> my implementation I have been using  one request Q upon which all 
requests
> are rcvd, and temporary Qs for the replies. When all is well this works
> just fine. However, when the connection to the Q mgr is lost the 
contents
> of the temporary Qs is lost. I realise this is the way that temporary Qs
> are supposed to work but it makes me wonder if temporary Qs are right 
for
> a long running server when the Q mgr may go away. What do people think?
>
> The other design I had in mind, which I have seen implemented elsewhere,
> is for the server to have a reply Q and clients use a message selector 
to
> get the reply for their correlation id. I am not sure I can do that
> because my client will actually be firing off several requests close
> together before getting a reply for any of them. So if I was to browse 
for
> replies I would have to watch out for all the correlation ids for any
> pending replies.
>
> I am on the verge of writing some recovery code that remembers the
> messages sent for which no reply has been rcvd yet and resends them on a
> reconnect. This is a little bit involved and makes me wonder if maybe I
> shouldn't be using temporary Qs after all. But I heard somewhere that
> temporary Qs are supposed to be the better solution, more scalable, 
better
> performance etc etc. Can anyone comment please?
>
> Regards,
>
> Andrew Marlow
>
> ___________________________________________________________
> 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.
>


___________________________________________________________
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.

--=_alternative 0036C78380257743_=--