Re: IgniteCompute.withAsync can execute tasks synchronously

[Andrey Gura]

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

On Thu, Feb 11, 2016 at 4:12 PM, Andrey Gura  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  > 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  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

Re: IgniteCompute.withAsync can execute tasks synchronously

[Dmitriy Setrakyan]

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  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
>