ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Which thread is used to run IgniteFuture continuations?
Date Mon, 12 Oct 2015 13:53:01 GMT
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 <yzhdanov@apache.org> 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 <vozerov@gridgain.com>:
>
> > 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.
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message