Fully asynchronous invocation

[dmlloyd]

In my wiki article, I talked about using a Future to represent the future result of an invocation in the event of a non-blocking request-reply invocation. One limitation of Future is that it doesn't provide any means to call a callback when the operation completes - you must poll the Future. So instead of returning a Future, the asynchronous request method should return a subinterface of Future (which I have called FutureReply) that also has a setCompletionNotifier(handler) method, which calls the given handler when the request completes.

This way, a single interface lets you invoke in three different ways: blocking, non-blocking with polling, and non-blocking with asynchronous callback.

[dmlloyd]

Expanding on this idea: there are two basic thread arrangements that affect asynchronous invocations.

The first is the stereotypical server methodology: basically a Selector and a thread pool. A message coming across the wire is (typically) handled immediately.

The second is the stereotypical client methodology: the client owns the connection, but there is no dedicated thread to handle asynchronous messages.

The FutureReply model can work with both of these models with varying degrees of success. With the server model, it's easy - messages are always handled immediately. If there's a request completion notifier registered on the FutureReply, the callback can be called instantly.

The client model is a little trickier, but still doable. Basically, any time a client thread makes a call into Remoting, the thread can be "borrowed" to do a bit of work, especially if it was just going to block anyway. This isn't a perfect solution, since if the user never calls into Remoting, they will never get their "asynchronous" notifications.

Perhaps these potential limitations are outweighed by the benefit of not having to deal with a dedicated thread pool on the client.

Alternatively, asynchronous calls could simply be disallowed if there's no thread available to monitor for replies.