activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexander L." <ferve...@yandex.ru>
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: http://www.nabble.com/Implement-request-response-with-JMS-over-Stomp-tp24914033p24931667.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.


Mime
View raw message