ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Gura <ag...@gridgain.com>
Subject Re: IgniteCompute.withAsync can execute tasks synchronously
Date Fri, 12 Feb 2016 16:47:14 GMT
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

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