Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAEOB7kV4Cw6C1Qctvb75y_e_xC2xK5_CMRZ8p3HJPZT3WE+E1g@mail.gmail.com>
References: 
 <CAEOB7kXEmL=8moNkz=ULCAxh4_Hz8xL=XhvimAcS3Gn2HB8pxw@mail.gmail.com>
	<CA+0=VoWMUWS6n=Aos0+TtqQyJH5GsdeY5VvNpwZu+bGTqw=BHQ@mail.gmail.com>
	<CAEOB7kV4Cw6C1Qctvb75y_e_xC2xK5_CMRZ8p3HJPZT3WE+E1g@mail.gmail.com>
Date: Fri, 12 Feb 2016 19:47:14 +0300
Message-ID: 
 <CAEOB7kW2xMUxNkY-tWKhbTW=gyjpDfpTh2OYUf6OE6J_Mfqgww@mail.gmail.com>
Subject: Re: IgniteCompute.withAsync can execute tasks synchronously
From: Andrey Gura <agura@gridgain.com>
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a1143920e52923b052b956b7c

--001a1143920e52923b052b956b7c
Content-Type: text/plain; charset=UTF-8

I've created ticket https://issues.apache.org/jira/browse/IGNITE-2646

On Thu, Feb 11, 2016 at 4:12 PM, Andrey Gura <agura@gridgain.com> wrote:

> Dmitry,
>
> GridTaskProcessor does't know what kind of IgniteCompute implementation
> was used by client code. So we need some kind of flag that will talk to
> GridTaskProcessor: "execute task in pool, not in caller thread".
>
>
> On Wed, Feb 10, 2016 at 11:56 PM, Dmitriy Setrakyan <dsetrakyan@apache.org
> > wrote:
>
>> Andrey,
>>
>> I think we should keep it simple. From the API standpoint, I am not sure
>> why not just always execute the task asynchronously every time when
>> withAsync() API is invoked? Why add additional parameters to the API?
>>
>> D.
>>
>> On Wed, Feb 10, 2016 at 6:53 AM, Andrey Gura <agura@gridgain.com> wrote:
>>
>> > Guys,
>> >
>> > during debugging of failed test
>> > (GridSessionCheckpointSelfTest.testSharedFsCheckpoint) I've noticed that
>> > GridTaskWorker can invoke reduce() method in caller thread.
>> >
>> > If task isn't annotated by @ComputeTaskMapAsync then mapping job will be
>> > run in caller thread. Since job mapping will be finished
>> > processDelayedResponses() method will be invoked and if delayed
>> responses
>> > queue isn't empty then caller thread can invoke reduce() method
>> eventually
>> > and perform reducing synchronously.
>> >
>> > It can be usefull in case of synchronous execution but, IMHO, it is very
>> > strange behavior for asynchronous case because user expects that method
>> > will return after creation of task.
>> >
>> > Similar behavior is possible for all places where code invokes
>> > GridTaskProcessor.execute() method (IgniteCompute.broadcast(),
>> > IgniteCAche.size(), REST handlers, etc.)
>> >
>> > I see three options in order to fix the problem:
>> >
>> > 1. Remove GridTaskWorker.processDelayedResponses() method and all calls.
>> > Perhaps, performance can sufer a little bit (but I'm not sure).
>> >
>> > 2. Add special flag to execute method (e.g. usePool) that will give
>> > guarantees that task will not be executed in caller thread. Of course
>> this
>> > flag should be add for all methods in call chain.
>> >
>> > 3. Use task process thread context (GridTaskProcessor.thCtx) and special
>> > key that will represent requirement about execution task in pool
>> similar to
>> > usePool flag.
>> >
>> > In case of 2nd and 3rd options we should analyze every usage of
>> > GridTaskProcessor.execute() method and solve should caller thread
>> execute
>> > task or not.
>> >
>> > Maybe I missed something and there is better way to solve this problem.
>> >
>> > I will be grateful for any advice or idea.
>> >
>> > --
>> > Andrey Gura
>> > GridGain Systems, Inc.
>> > www.gridgain.com
>> >
>>
>
>
>
> --
> Andrey Gura
> GridGain Systems, Inc.
> www.gridgain.com
>


-- 
Andrey Gura
GridGain Systems, Inc.
www.gridgain.com

--001a1143920e52923b052b956b7c--