activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander L." <>
Subject Re: Implement request response with JMS over Stomp
Date Wed, 12 Aug 2009 08:04:29 GMT

Hi Jose,

Thanks for your attention again,

Jose Luna-2 wrote:
> 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
That's right when services know their names/numbers. When services are not
assigned their names prior to talking with server, that is difficult to
arrange such set of queues.

Jose Luna-2 wrote:
> 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).

These two approaches may be combined in the following way:
1. Common queue /queue/requests may be used for services to inquire their
private queue (which may not exist at the time of request and must be
created by server)
Common queue /queue/responses may be used for services to retrieve names of
their private queues.
2. These private queues created by server play roles of temporary queues.
And there the question appears: what if the client dies without
unsubscribing? The queue is left unattended and some kind of unused queues
collector is needed.

Jose Luna-2 wrote:
> 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.   
AFAIK, JMS API does not have means to check whether queue has any clients.
Therefore such plugin should cooperate with broker implementation directly.
Hopefully this is possible.

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

View raw message