[
https://issues.apache.org/jira/browse/IGNITE-14841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391416#comment-17391416
]
Alexander Lapin commented on IGNITE-14841:
------------------------------------------
I don't like an idea of making different raft groups dependent of one another.
Within the proposed approach with striped disruptor if some group keeps one of
disruptor threads all other groups that share given thread will wait. Assuming
that both partitions A and B share same disruptor thread, are you sure that
there won't be any deadlocks, for example, in case of two concurrent
transactions touching partitions A and B and B and A respectively?
Also pay attention that after merging [node stop
logic|https://issues.apache.org/jira/browse/IGNITE-15148] to master additional
maintenance is expected - splitting constructors and proper component.stop()
implementation.
All in all, if we still follow the concept of cross partition shared *striped*
threads, patch looks good to me except one minor related to JRaftUtils.bootstrap
{code:java}
Am I right that JRaftUtils isn't a part of test package? If true it's strange
to see "unittest" and "new PeerId("127.0.0.1", 0)" here. Is there any sense in
bootstrap method in non-test environment? If not, did you consider moving
bootstrap to test env?
{code}
> Use shared distruptor pool for multiple raft group nodes.
> ---------------------------------------------------------
>
> Key: IGNITE-14841
> URL: https://issues.apache.org/jira/browse/IGNITE-14841
> Project: Ignite
> Issue Type: Task
> Reporter: Alexey Scherbakov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently raft uses a thread per raft group per server bound to several
> distuptor instances.
> It doesn't scale well if the number of groups started on a single server is
> significant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
