Async request/response

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

I am looking at building a async request/response framework. I have some
basic questions:

1) I want to hear from users about their experience who have already built
it. How successful it was? What to watch far etc.
2) I am thinking of creating 2 temp queues per thread one for request and
second for responde and use that to send request and response to the
clients. Is that a good way of building this framework?
3) How do you generally deal with failures and issues? Cases like:
            a) request was sent but the requesting thread returned to
caller before the response comes in the queue. Would this lead to building
of queue ?
            b) Cases where responses don't arrive on time?
            c) Application failures

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

Re: Async request/response

[artnaseef <ar...@artnaseef.com>]

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.