activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pico Florin <>
Subject Request/Reply pattern implementation dilemma
Date Mon, 09 Oct 2006 08:35:21 GMT
    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
  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
    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,

 All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." -
PC Magazine
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message