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.