[jira] [Created] (IGNITE-2646) IgniteCompute.withAsync can execute tasks synchronously
Andrey Gura created IGNITE-2646:
---
Summary: IgniteCompute.withAsync can execute tasks synchronously
Key: IGNITE-2646
URL: https://issues.apache.org/jira/browse/IGNITE-2646
Project: Ignite
Issue Type: Bug
Components: compute
Affects Versions: 1.5.0.final
Reporter: Andrey Gura
Assignee: Andrey Gura
{{GridTaskWorker}} can invoke {{reduce}} method in caller thread.
If task isn't annotated by {{@ComputeTaskMapAsync}} then job mapping 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, it is 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.)
Rerated discussion on dev-list: [IgniteCompute.withAsync can execute tasks
synchronously|http://apache-ignite-developers.2346864.n4.nabble.com/IgniteCompute-withAsync-can-execute-tasks-synchronously-td7262.html]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: IgniteCompute.withAsync can execute tasks synchronously
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
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
Re: IgniteCompute.withAsync can execute tasks synchronously
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 >
IgniteCompute.withAsync can execute tasks synchronously
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
