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 >
