Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
Subject: Re: Make async API great again
To: dev@ignite.apache.org
References: <CAGt6o8k_prXL301ooihB1efjgrAXSPHL0UnrNM34k_rAEPUR8w@mail.gmail.com>
 <CAK2_iMNx_vA97nGxBLCvH8qTG1YAhmwEz20FYYrJi1Vj3Prkng@mail.gmail.com>
From: =?UTF-8?B?5p2O546J54+PQDE2Mw==?= <18624049226@163.com>
Message-ID: <0326bca8-0290-154f-e52d-92d1981f8f63@163.com>
Date: Tue, 20 Dec 2016 21:59:15 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0)
 Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CAK2_iMNx_vA97nGxBLCvH8qTG1YAhmwEz20FYYrJi1Vj3Prkng@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
archived-at: Tue, 20 Dec 2016 14:17:28 -0000

+1


在 2016/12/20 18:05, Pavel Tupitsyn 写道:
> Huge +1 on this. Current API is very confusing.
>
> On Tue, Dec 20, 2016 at 11:56 AM, Vladimir Ozerov <vozerov@gridgain.com>
> wrote:
>
>> Igniters,
>>
>> We have complaints about design of our async API, and upcoming Ignite 2.0
>> release is a good candidate to fix it.
>>
>> Problems:
>>
>> 1) API is verbose and error prone:
>>
>> Ignite asyncCache = cache.withAsync();
>> asyncCache.get(key);
>> IgniteFuture<V> fut = asyncCache.future();
>>
>> 2) Hard to reason which methods support async execution and which are not.
>> @IgniteAsyncSupported is not user friendly because it forces users to read
>> JavaDocs thoroughly.
>>
>> 3) No control on where IgniteFuture.listen() and IgniteFuture.chain()
>> methods are executed. User can easily inadvertently add some code which
>> will lead to starvation. E.g.:
>>
>> IgniteFuture<V> fut = asyncCache.future();
>> fut.listen((fut) -> { cache.put(...); }); // Starvation because callback
>> might be executed in sys pool.
>>
>> 4) We have incorrect IO optimization: if message is to be send to local
>> node, it will be executed synchronously. See GridIoManager.send() method.
>> This is wrong, because it breaks pool semantics. E.g. cache operations must
>> be executed in sys pool, but can be executed in public pool.
>>
>> I propose to fix all that problems in Apache Ignite 2.0:
>>
>> 1) Let's have simple and straightforward API:
>> IgniteFuture<V> fut = cache.getAsync(key);
>>
>> 2) Fix local node "optimization" in GridIoManager - messages should not be
>> processed synchronously.
>>
>> 3) User continuations must never be executed synchronously, always delegate
>> them to public pool by default (or may be to Java FJP?).
>>
>> 4) Allow users to specify thread pool for their continuations:
>> IgniteFuture.listen(Closure, ExecutorService);
>> IgniteFufure.chain(Closure, ExecutorService);
>>
>> See Akka "Dispatcher" [1] as example of similar concept.
>>
>> Thoughts?
>>
>> [1] http://doc.akka.io/docs/akka/current/scala/dispatchers.html
>>
>> Vladimir.
>>