Mailing-List: contact activemq-users-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: activemq-users@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Request/Reply pattern implementation dilemma
Date: Mon, 9 Oct 2006 09:43:21 +0100
Message-ID: <642D4A2F32D7BD42A0C1F7F3EDD0773A229897@ex1.hpd.int>
Thread-Topic: Request/Reply pattern implementation dilemma
Thread-Index: AcbrfghUX6RDsj1vTwuv1GltCu8vVgAABBHQ
From: "Charles Anthony" <charles.anthony@hpdsoftware.com>
To: <activemq-users@geronimo.apache.org>

Hi,

In our application, We use the second approach (temporary queues).

You can create a producer with a null destination
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html#createProdu
cer(javax.jms.Destination)

and specify the destination on the send.


This is what losely we do :


this.replier =3D session.createProducer(null)

....
public void onMessage(Message message) {
   Destination replyQueue =3D message.getJMSReplyTo();
   ..
   replier.send(replyQueue, reply);
}

HTH,

Charles.

> -----Original Message-----
> From: Pico Florin [mailto:picoflorin@yahoo.co.uk]=20
> Sent: 09 October 2006 09:35
> To: activemq-users@geronimo.apache.org
> Subject: Request/Reply pattern implementation dilemma
>=20
> Hi!
>     I have a P2P architecture where  clients send messages to=20
> a  JMS server and they are expecting for a reply. I have seen=20
> two  solutions for implemementing this:
>    1. The client has a predefined reply queue where it=20
> expects the reply messages from the server.
>   2. The client has a temporary queue  it expects the reply=20
> messages from the server.
>  =20
> I have implemented the solution 1 and I've noticed this drawback:
>    If the client is shutdown and the server didn't send all=20
> reply  messages for it, next time when the client is=20
> connected the server will  send the unsent messages=20
> eventhough the server is set up do not keep a  journal.=20
>   The question is how can I consume or discard the unsent=20
> messages in  order to have the reply queue empty for the next=20
> connection of the  client? How can I know when the client is=20
> shutdown (is not connected  anymore to the server)?
>   For the soution 2 I've noticed the following:
>      The drawback that appears in solution 1 does't appear in=20
>  this soultion, meaning when the client is shutdown and it=20
> reconnects to  the server it will not receive the remained=20
> unsent messages.
>     A major drawback appears: you should create per each=20
> message the  producer that il will send the message by using=20
> somehow this code:
>    (supposing that the received message from the server is=20
> msg and  the producer for the replying is named replyProducer=20
> and the setup for  connection, session are done it)
>   public void onMessage(Message msg) {
>    ...
>       replyProducer =3D session.createProducer(msg.getJMSReplyTo());
>    ... =20
>       This approach has a huge impact on the server memory =20
> when you send a high volume of messages even when you have=20
> just one  user who is connected.
>   I have made a producers pool as I described for the=20
> solution one but it  has a setback: each time the client is=20
> connected to the server I retain  the destionation and the=20
> producer in the pool and each time is  different because I=20
> use temporary queue. The producers pool is a  synchronized=20
> hasmap that has as a key the destination of the for the =20
> repply message and its producer. The problem can be solved=20
> again if I  can test if the client is still connected or no,=20
> thus I can free up the  producer pool for unactive clients.
>    Any suggestions and ideas regarding this issues are well=20
> appreciated.
>  =20
>   Thank you,
>      Florin
>  =20
>  =20
>  =20
>  =20
>     =20
>    =20
>    =20
>    =20
>  =20
>   =20
>=20
>  	=09
> ---------------------------------
>  All new Yahoo! Mail "The new Interface is stunning in its=20
> simplicity and ease of use." - PC Magazine
>=20