Details
-
Improvement
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
None
-
None
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:
private final Worker worker = new Worker(); ... workerThread = threadFactory.newThread(worker);
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
Attachments
Issue Links
- relates to
-
IGNITE-15510 RaftGroupServiceImpl creates new ExecutorService for every instance
-
- Resolved
-
- links to
