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 Thu, 11 Feb 2016 13:12:19 GMT
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

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