[concurrency-interest] Joining on multiple futures (ListenableFuture?)

Rowlands, Ben (IT) Ben.Rowlands at morganstanley.com
Tue Dec 18 13:54:20 EST 2007

Are there any utilities in j.u.c to help join on multiple futures? For
 // returns when all futures complete or a future fails
 join( Future... futures, long timeout, TimeUnit unit )

A trivial implementation would loop through each future and call get().
This would work, and we could keep track of the time spent waiting on
each future to support a timeout. 

The main drawback of this technique is we only find out about a failed
future after we've called get() on all previous futures. We'd like to
learn about a failure as soon as possible to start recovery (if any
futures fail we repeat the unit of work, so the sooner we can detect a
failure the better). We cancel any pending futures before the repeat.

Our alternative implementation uses polling by calling get() with a
timeout of a few hundred ms and looping until all complete. This works
but isn't terribly elegant, and has caused some problems with poorly
implemented futures (the polling basically gets pushed down to the
resource the future wraps, often a read on a TCP socket within the

In our use-case, the futures are backed by tcp sockets (they hold the
result of a tcp request). One solution might be support for
"ListenableFutures" that notify a listener when they complete (or fail
with an exception), allowing us to use a more efficient strategy to join
on the futures. Something like:

  interface ListenableFuture extends Future {
    // register a listener to be called when this future is 'ready' (has
a result or failed)
    // if the future is already complete the callback is fired
    void registerListener( FutureListener listener );

  interface FutureListener {
    void ready( Future future );

I'd guess there are other Futures that could support asynchronous
notification on completion including async file IO.

Are there any plans to support anything like this? Or have we missed
something obvious? I came across a discussion back in 2003 related to
this but it looks like the done() subclass hook that resulted is more
for implementers of futures than consumers of the future(s).




NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

More information about the Concurrency-interest mailing list