[ https://issues.apache.org/jira/browse/IGNITE-15528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17444551#comment-17444551 ]
Alexey Scherbakov commented on IGNITE-15528: -------------------------------------------- I've reverted a change which removes assertion in org.apache.ignite.internal.raft.server.impl.JraftServerImpl#stop > 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-alpha4 > > > 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.20.1#820001)