[jira] [Updated] (IGNITE-15528) JRaft creates at least 4 threads for every raft group on a leader

["Mirza Aliev (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mirza Aliev updated IGNITE-15528:
---------------------------------
    Description: 
When we create a raft group on a leader, jraft creates at least 4 threads for every raft group: one thread for {{electionTimer}}, {{voteTimer}}, {{stepDownTimer}}, and {{snapshotTimer}}. To be more precise, every timer is an instance of {{HashedWheelTimer}}, which creates one thread:
{code:java}
private final Worker worker = new Worker();  
...
workerThread = threadFactory.newThread(worker);
{code}
This fact leads to restrictions on the number of partitions that might be created, as far as every partition is associated with a raft group. For example, one table with 1024 partitions leads to at least 4096 threads on a single node.

Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make any sense, as far as the workload of the shared executor likely will lead to instability of cluster because threads are timer threads (election timer, for example).

A possible solution is to implement batched handling of raft groups requests, like {{appendEntriesRequest}}. In this approach, timers could be shared by raft groups.

  was:
When we create a raft group on a leader, jraft creates at least 4 threads for every raft group: one thread for {{electionTimer}}, {{voteTimer}}, {{stepDownTimer}}, {{snapshotTimer}}. To be more precise, every timer is an instance of {{HashedWheelTimer}}, which creates one thread:
{code:java}
private final Worker worker = new Worker();  
...
workerThread = threadFactory.newThread(worker);
{code}

This fact leads to restrictions on the number of partitions that might be created, as far as every partition is associated with a raft group. For example, one table with 1024 partitions leads to at least 4096 threads on a single node.

Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make any sense, as far as the workload of the shared executor likely will lead to instability of cluster because threads are timer threads (election timer, for example).

A possible solution is to implement batched handling of raft groups requests, like {{appendEntriesRequest}}. In this approach, timers could be shared by raft groups.


> JRaft creates at least 4 threads for every raft group on a leader 
> ------------------------------------------------------------------
>
>                 Key: IGNITE-15528
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15528
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Mirza Aliev
>            Priority: Blocker
>              Labels: ignite-3
>             Fix For: 3.0.0-alpha3
>
>
> When we create a raft group on a leader, jraft creates at least 4 threads for every raft group: one thread for {{electionTimer}}, {{voteTimer}}, {{stepDownTimer}}, and {{snapshotTimer}}. To be more precise, every timer is an instance of {{HashedWheelTimer}}, which creates one thread:
> {code:java}
> private final Worker worker = new Worker();  
> ...
> workerThread = threadFactory.newThread(worker);
> {code}
> This fact leads to restrictions on the number of partitions that might be created, as far as every partition is associated with a raft group. For example, one table with 1024 partitions leads to at least 4096 threads on a single node.
> Changing {{HashedWheelTimer}} to {{DefaultTimer}} with shared pool won't make any sense, as far as the workload of the shared executor likely will lead to instability of cluster because threads are timer threads (election timer, for example).
> A possible solution is to implement batched handling of raft groups requests, like {{appendEntriesRequest}}. In this approach, timers could be shared by raft groups.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)