activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Luna <>
Subject Re: Implement request response with JMS over Stomp
Date Tue, 11 Aug 2009 21:38:47 GMT
> 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 (,
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:


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, 


> -- 
> View this message in context: 
> Sent from the ActiveMQ - User mailing list archive at


View raw message