Thank you Charles for you suggestion. It realy works. The server now is much
more stable ( the memory doesn't grow too much).
Regards,
Florin
Charles Anthony <[EMAIL PROTECTED]> wrote: 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 = session.createProducer(null)
....
public void onMessage(Message message) {
Destination replyQueue = message.getJMSReplyTo();
..
replier.send(replyQueue, reply);
}
HTH,
Charles.
> -----Original Message-----
> From: Pico Florin [mailto:[EMAIL PROTECTED]
> Sent: 09 October 2006 09:35
> To: [email protected]
> Subject: Request/Reply pattern implementation dilemma
>
> Hi!
> I have a P2P architecture where clients send messages to
> a JMS server and they are expecting for a reply. I have seen
> two solutions for implemementing this:
> 1. The client has a predefined reply queue where it
> expects the reply messages from the server.
> 2. The client has a temporary queue it expects the reply
> messages from the server.
>
> I have implemented the solution 1 and I've noticed this drawback:
> If the client is shutdown and the server didn't send all
> reply messages for it, next time when the client is
> connected the server will send the unsent messages
> eventhough the server is set up do not keep a journal.
> The question is how can I consume or discard the unsent
> messages in order to have the reply queue empty for the next
> connection of the client? How can I know when the client is
> 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
> this soultion, meaning when the client is shutdown and it
> reconnects to the server it will not receive the remained
> unsent messages.
> A major drawback appears: you should create per each
> message the producer that il will send the message by using
> somehow this code:
> (supposing that the received message from the server is
> msg and the producer for the replying is named replyProducer
> and the setup for connection, session are done it)
> public void onMessage(Message msg) {
> ...
> replyProducer = session.createProducer(msg.getJMSReplyTo());
> ...
> This approach has a huge impact on the server memory
> when you send a high volume of messages even when you have
> just one user who is connected.
> I have made a producers pool as I described for the
> solution one but it has a setback: each time the client is
> connected to the server I retain the destionation and the
> producer in the pool and each time is different because I
> use temporary queue. The producers pool is a synchronized
> hasmap that has as a key the destination of the for the
> repply message and its producer. The problem can be solved
> again if I can test if the client is still connected or no,
> thus I can free up the producer pool for unactive clients.
> Any suggestions and ideas regarding this issues are well
> appreciated.
>
> Thank you,
> Florin
>
>
>
>
>
>
>
>
>
>
>
>
> ---------------------------------
> All new Yahoo! Mail "The new Interface is stunning in its
> simplicity and ease of use." - PC Magazine
>
---------------------------------
Try the all-new Yahoo! Mail . "The New Version is radically easier to use"
The Wall Street Journal
