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
