activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mohit Anchlia <>
Subject Re: Async request/response
Date Tue, 02 Sep 2014 18:41:41 GMT
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 <> 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:
> Sent from the ActiveMQ - User mailing list archive at

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message