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 Thu, 15 Oct 2015 16:59:10 GMT
Folks,

It looks like the problem is deeper and is not limited to futures. It
relates to any user code. For example:

1) Register either local or remote message listener:
Ignite.message().localListen("myTopic", myLsnr);

2) Send a message to the topic from the same node:
Ignite.message().send("myTopic", "Hello world!");

As a result, listener will be invoked synchronously from the same thread.
It means we cannot utilize resources efficiently in case of local message.

On Mon, Oct 12, 2015 at 7:51 PM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> On Mon, Oct 12, 2015 at 9:39 AM, Vladimir Ozerov <vozerov@gridgain.com>
> 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 <
> dsetrakyan@apache.org>
> > 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 <vozerov@gridgain.com
> >
> > > 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 <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