Hi ASAIK there is no mechanism that allows a response back to a JMS client that originally created the message.
But we could build such features ourselves.
I could find three ways:
1) QueueRequestor ( TopicRequestor ).
2) Temporary Queues.
3) Topic with message selectors.
What to choose ?
Better performance ?
Opinions from anyone with JMS skills!
Thank you for your time.
Actually, you can specify a reply queue with the original message. The target canthen send to that queue, and pass the original message id as the correlation id. Your waiting client then tries to read from its reply queue using that correlation id.
I'm not very sure what is the goal of your specific design. The JMS is by definition asynchronous, so client should not wait for anything. Response processing should be done in parallel, sharing data through some persistence.
However there are some situations where you would need that. In our app, to emulate synchronous request/response on asynchronous system we have used two queues, 'client-to-server' and 'server-to-client'. Client sends messages to 'client-to-server' queue. Every message carries 'request ID' which is used by server to create reply (replyId). Client does receive() on 'server-to-client' queue with timeout on queue with filter by 'replyId'.
With this approach, there are additional challenges such as gracefully handling timeouts (when JMS response didn't arrive in reasonable time), re-sending requests ensuring they have same IDs and preventing requests from being processed twice.
Yes sometimes there is a need for a synchronous work, such as a P2P solution. And the requestor has to accept the blocking limitation.
To achieve a solution that fits problem below (pseudo).
return response.getText(); // Pirates of the Caribbean
Now back to my three choices.
Your solution fits in the category 2- Temporary Queues.
The solution is acceptable but I find it as performance killer in a view of the filter usage.
Using Temporary Queue solution is easy to implement but what will happen if you filter on large queues?
Your client will walk through all messages over and over again until finding the message that fits your filter. This is an overload. Same solution with Topic each message is compared against all consumers once and exactly once. There will never be any duplicated work.
IMO the topic solution performs better.
If I go with some synchronous P2P solution, I would choose between 1 and 3.
1- QueueRequestor / TopicRequestor
+ basic request/response mechanism
+ few code lines
2- Temporary Queues
+ easy to implement
+ immediate notifcation
- performance killer when filtering large queues.
- no persistent
3- Topic solution
+ better fault tolerance
+ better filtering ("exactly once filtering")
- secure (anyone can register a consumer to a topic)
My requierments are few:
a* acceptable response time.
b* good performance
Solution 1 (Requestor) is in this case excluded, since it blocks till timeout (?).
Solution 2 is a performance killer with large queues and complicated selectors.
Solution 3 fits my requierments.
For more information - Mastering EJB II.