On Mon, Oct 12, 2015 at 9:39 AM, Vladimir Ozerov <[email protected]> wrote:
> It would be cool, but CompletableFuture is available since Java 8. > Well, we could add some methods from CompletableFuture to IgniteFuture then. I will take a look and suggest a few. > > On Mon, Oct 12, 2015 at 7:25 PM, Dmitriy Setrakyan <[email protected]> > wrote: > > > Would it be possible for us to support CompletableFuture from Java > instead > > of adding one-off methods? > > > > On Mon, Oct 12, 2015 at 6:53 AM, Vladimir Ozerov <[email protected]> > > wrote: > > > > > 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. > > > > > > > > > > > > > > >
