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.
