[ 
https://issues.apache.org/jira/browse/IGNITE-4699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930038#comment-15930038
 ] 

Alexander Menshikov commented on IGNITE-4699:
---------------------------------------------

[~tledkov-gridgain] [~vozerov]
Thank you for answer.
I think this is not good idea to give users ability to create new thread pools. 
And problem which you describe we can fix other way.

We can make the max number of threads is unlimited and add a ''waitCreateTime" 
which will give a delay between adding a new task and create a new thread for 
the task. Like "keepAliveTime" but on the contrary. So if a lot of short tasks 
will come to grid then thread pool with "waitCreateTime" will not create a lot 
of unnecessary thread and will work like now. But if one task remain in queue a 
lot of time then thread pool create new thread. I think it's better solution 
because:

1. Users can't create more threads than they need.
2. Users don't need to manage all these new thread pools.
  2.1. There is no problems with reuse thread pools.
  2.2. There is no problems with remove old thread pools.
  2.3. API will not change. Old programs will start work better.
3. There is no competition of different thread pools for physical resources.
4. It can help in some other place where we use thread pools.

Alternative. Users can add task information about what it contains subtasks or 
not. And reserve one thread for every task with sub tasks. This will solve the 
problem too, but worse than the previous solution because if a task with sub 
tasks will create a short subtask only at the end of work, then all this time 
when the task are executing, we will have one unused thread.

And other alternative is auto create new thread pools for subtask. We will have 
some kind of pool of thread pools where one pool for one level of sub tasks. It 
worse than my first solution because it harder to manage thread pools than 
threads (if we have one unused thread it's okay, but if we have one unused 
thread pool it's mean we have a lot of unused threads).

> Introduce custom configurable executors.
> ----------------------------------------
>
>                 Key: IGNITE-4699
>                 URL: https://issues.apache.org/jira/browse/IGNITE-4699
>             Project: Ignite
>          Issue Type: Task
>          Components: compute
>            Reporter: Vladimir Ozerov
>            Assignee: Alexander Menshikov
>             Fix For: 2.0
>
>
> We need to provide a way to configure custom thread pools for user compute 
> tasks. 
> Proposed API:
> 1) Config
> {code}
> class ExecutorConfiguration {
>     String name;
>     int size;
> }
> {code}
> 2) Choosing executor for compute task:
> {code}
> IgniteCompute compute = Ignite.compute().withExecutor("my_exec");
> {code}
> 3) Accessing raw executor (could be required for proper execution of future 
> listeners):
> {code}
> ThreadPoolExecutor exec = ignite.compute().localExecutor("my_exec");
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to