> If I understood right, then each requesting service A (A1...An) should > maintain its own unique correlation id (permanent during the connection's > life).
My initial suggestion was actually to have a unique correlation-id for each request. This provides greater granularity than the above proposal, but has the overhead of creating/destroying a consumer for every request. In short, my initial suggestion wasn't a very good one (especially if you're processing a very large volume of request/response messages). I realized that not having access to temporary queues is actually not a very big limitation as long as you can provide unique queues for the services that are making the request. If you read about the suggested way to implement request-response (http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html), you'll see that temporary queues are not strictly required. You have to be sure to include the reply-to destination in the request, and then you know which destination to check for the response. Since we don't have access to temporary destinations, we simply make sure that destination exists before making requests. So the requesters A1, A2, and A3 might create the following queues: /queue/responses.A1 /queue/responses.A2 /queue/responses.A3 Then, when A1 makes a request, it sets the reply-to header to "/queue/responses.A1", and then checks that queue for the response. Of course, we can still use the correlation-id to correlate the requests and responses. The benefit of using the temporary queue is that the queue is destroyed when the consumer unsubscribes. So without temporary queues, we need to have a finite number of requesters with some way to uniquely identify themselves. If this requirement cannot be met, then our queue creation could easily get out of control. In other words, we could end up with thousands of queues of the form /queue/responses.{ID}. This can cause problems with resource usage (memory and threads). If your particular use case can't provide a limited number of unique services, I can think of two possible solutions: 1.) Set your broker config so that it doesn't create previous queues when starting up, then set up a cron job (or windows task schedule) to restart the broker nightly or weekly. This is the cheap solution and would require that you don't need persistence. 2.) Create a broker plugin that destroys any queues that matches /queue/responses.* when the consumer unsubscribes. This is the better long-term solution, and it's essentially mimicking temporary queue behaviour. Hope that helps, 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.
