Jose, Thank you for the solution. =)
If I understood right, then each requesting service A (A1...An) should maintain its own unique correlation id (permanent during the connection's life). That way message broker could decide which requesting service An to route message to if two or more requesting services (Ak, Am,...) are trying to consume message from the /queue/responses at the same moment. Is that correct understanding of your idea? I realize that it's not very secure. Let's imagine that one of requesting services (A) could go greedy and consume all messages from the queue (by omitting selector). Using topic instead of queue would solve that issue. One greedy service will not steal messages from the topic, though still all services might observe the message which is destined for single one if they omitted selector. Meanwhile this is still best solution I could imagine now. Alex. Jose Luna-2 wrote: > > You can use two normal (non-temporary) queues, one for requests and one > for responses. Each request will have a correlation-id header. Let's > call the requesting service A and the responding service B. Service A > will send to /queue/requests. Service B will receive (consume) the > request, and send the response to /queue/responses. The response that > Service B sends will have a correlation-id that matches the request. > Service A can then subscribe to /queue/responses with a selector > (http://activemq.apache.org/selectors.html) that matches the > correlation-id. Therefore, Service A will only consume the response that > matches the correlation-id of the request. > > JLuna > -- View this message in context: http://www.nabble.com/Implement-request-response-with-JMS-over-Stomp-tp24914033p24919423.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
