Re: Async request/response

[Mohit Anchlia <mo...@gmail.com>]

If I use queues that are not temp for request/reply than the challenge is
that somehow I need to maintain the context of the calling thread and then
dispatch the response to the correct thread. It becomes rather difficult to
do that.

Currently, this is what I am doing:

1) Create connection, session and a temp queue (for responses)  per thread
and cache it in thread local
2) Create a consumer per thread and a future object backed by
ArrayBlockingQueue per thread
3) thread sends the request and then calls Future.get() with a timeout.
4) Receiver/consumer receives the response and adds that to the queue,
which then ublocks thread in step 3

With shared request and response queues it becomes difficult to dispatch
the response to the caller thread.


On Thu, Aug 28, 2014 at 7:54 PM, artnaseef <ar...@artnaseef.com> wrote:

> Temporary destinations may work well, although you'll want to watch out for
> these:
>
> * Large numbers of temporary destinations may be a strain on the broker
> * Creation of temporary destinations in a network-of-brokers leads to race
> conditions (i.e. temp destination message flow is unreliable)
>
> Other tips:
>
> * How can temp destinations be used for requests? Specifically, how would
> the requestor's know the temporary destinations to use when sending
> requests?
> * Temporary destinations are linked to a connection, so closing the
> connection removes the temp destination; producing to such a temp
> destination fails (a good thing).
> * Reusing a single temporary destination across the life of a connection is
> a good thing; especially in a network of brokers as race conditions exist
> primarily around creation and deletion of temp destinations and not so much
> when just sending messages across already-fully-established temp dests.
> * Requestor's likely need to handle the case of receiving a late response
> (i.e. a response coming after the request expired); I recommend just
> logging
> it.
> * Avoid creating and removing consumers repeatedly.  Using dedicated
> consumer threads that then "hand-off" to requestor threads is a good
> architectural solution.
>
> A high-level thought here: rather than trying to use activemq to connect
> request-to-reply (e.g. a single destination for a single exchange), it
> generally works far better to use activemq to connect server-to-server, or
> even at a higher level of abstraction, and use handling inside each server
> to connect between activemq messages and the request/reply handlers.  For
> example, if there are 100 request processors running on a single server (ie
> JVM), have that JVM listen on a single queue for requests and internally
> dispatch across the 100 request handlers.  If the request handlers are not
> homogeneous (i.e. requests need to go to individual, or subsets, of the
> request handlers), include metadata in the form of activemq message
> properties is a good way to differentiate.
>
> Hope this helps.
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Async-request-response-tp4685077p4685127.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>