Yakov, two points there: 1) This is a matter of convenience. Current mainstream solution for similar tasks is Java's CompletableFuture. Here is what it offers: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#runAsync-java.lang.Runnable- https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#runAsync-java.lang.Runnable-java.util.concurrent.Executor-
2) Probably we should go event further and do not execute continuations in user thread or our system threads by default because this is error prone and is subject to deadlocks and unpredictable slowdowns in normal compute/cache operations. By default we can either delegate to FJP, provide configurable pool for continuations, or use Ignite public pool. On Mon, Oct 12, 2015 at 4:25 PM, Yakov Zhdanov <[email protected]> wrote: > Not sure if I get the point. You can do exactly the same inside your > listener. > > final Executor executor = ...; > > // Bla-bla > > cache.future().listen(() => { > executor.execute(new Runnable() { > latch.await(); > /** Do something useful. */ > } > }); > > --Yakov > > 2015-10-09 17:22 GMT+03:00 Vladimir Ozerov <[email protected]>: > > > Igniters, > > > > We are missing an ability to specify which thread should run continuation > > routine when future is completed. > > > > Currently we either run routine in the callee thread or in completion > > thread (usually system pool thread). It means user cannot have any > blocking > > or cache operations inside the continuation. The code below could > surprise > > user with either a deadlock or system pool starvation: > > > > final CountDownLatch latch = new CountDownLatch(); > > > > Cache cache = ignite.cache().withAsync(); > > cache.invoke(...); > > > > cache.future().listen(() => { > > latch.await(); > > /** Do something useful. */ > > }); > > > > /** Do something else. */ > > latch.countDown(); > > > > Java 8 and Hazelcast already support custom thread pools for > continuations. > > E.g.: > > Hazelcast.CompletableFutureTask.andThen(ExecutionCallback<V> callback, > > Executor executor); > > > > Looks like we should allow users to specify optional thread pool in > futures > > likewise. > > > > Thoughts? > > > > Vladimir. > > >
