[concurrency-interest] Composing multiple tasks into a single Future/FutureTask

Ariel Weisberg ariel at weisberg.ws
Tue Apr 17 19:38:36 EDT 2012


I am using Future and ListeningFuture interchangeably.

There isn't a causal relationship. The fsync task exists at the
time the overall put Future is created, but it isn't run until
some time later.

The thread running the fsync task has to cause all the put
Futures depending on it to enter the completed state and then all
the listeners have to be notified.

It seems like I want some combination of Guava's
ListenableFutureTask and maybe extending

If the fsync action were a ListenableFutureTask I could forward
the the listener registrations to it. However part of the return
value is specific to each put (latency, compression ratio etc.).
Also cancel and related wouldn't go to the fsync Future either,
it would go to the write Future. If I bind the Future for the
fsync task and the Future for the write task and then extend
ForwardingFuture I could point each method to the correct place.
That is probably the "simplest" way to do it, but I wanted to
avoid extending a Future implementation and adding custom

I think it is mostly co-incidence that I happen to be able to map
the various methods of ListenableFuture usefully to the two other
ListenableFutures (fsync tasks, write task) and it doesn't seem
like a great design pattern.

Akka is definitely something that interests me, especially the
distributed aspects, but it is a  lot to take on to solve this


On Wed, Apr 18, 2012, at 12:44 AM, √iktor Ҡlang wrote:

  Hi Ariel,

Akka's got composable
Futures: [1]http://doc.akka.io/docs/akka/2.0/java/futures.html

Essentiall, what you're looking for is the "andThen" operation:


val resultingFuture = Future { compressAndChecksum(payload) }
andThen { _ => fsync() }


On Tue, Apr 17, 2012 at 5:39 PM, Ariel Weisberg
<[2]ariel at weisberg.ws> wrote:

  Hi all,
  I have been looking for the right way to build an API that
  returns a
  Future that is composed of tasks that will be performed in
  stages, potentially from more than one thread.
  My use cases is a disk based persistence store. The initial
  put API
  call creates a task that compresses and checksums the payload.
  resulting Future is bound in a Runnable and submitted to a
  thread ExecutorService that timestamps the entry and appends
  it to a
  file and it is the Future of the second task that is currently
  by the API.
   The trick is that the Future that is returned by the put call
   not complete until the write is durable. Writes are made
  durable by
   periodically invoking fsync from a dedicated thread or by
   write threads as each blocks on fsync/force. This allows for
   commit at an interval the IO device can handle without
  Ideally I could create a FutureTask that is composed of
  several other
  Futures, some of which will not exist when the FutureTask is
  created and returned by the API. I do know how many
  dependencies there
  will be
  expected up front.
  If I had such a thing I would create a task to do the fsync
  and add it
  as the last dependency to every Future read by the put API
  This would be a lot easier if I were willing to have many
  standing around blocking on Futures, but that rubs me the
  wrong way. It
  isn't fun to jstack and see all the noise.
  I suspect that there is something in Guava
  com.google.common.util.concurrent.Futures to handle this case,
  but it
  isn't jumping out at me.
  Ariel Weisberg
  Concurrency-interest mailing list
  [3]Concurrency-interest at cs.oswego.edu

Viktor Klang
Akka Tech Lead
[5]Typesafe - The software stack for applications that scale
Twitter: @viktorklang


1. http://doc.akka.io/docs/akka/2.0/java/futures.html
2. mailto:ariel at weisberg.ws
3. mailto:Concurrency-interest at cs.oswego.edu
4. http://cs.oswego.edu/mailman/listinfo/concurrency-interest
5. http://www.typesafe.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120417/574b8cba/attachment-0001.html>

More information about the Concurrency-interest mailing list