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 <a...@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. >