I've created ticket https://issues.apache.org/jira/browse/IGNITE-2646
On Thu, Feb 11, 2016 at 4:12 PM, Andrey Gura <ag...@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 <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 > -- Andrey Gura GridGain Systems, Inc. www.gridgain.com
