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 <dsetrak...@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 <ag...@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
