[
https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov reassigned IGNITE-15528:
------------------------------------------
Assignee: Alexey Scherbakov
> 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
> Assignee: Alexey Scherbakov
> 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. There is an issue in original JRaft repo with some close ideas
> https://github.com/sofastack/sofa-jraft/issues/672
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
