You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Kirill Gusakov (Jira)" <ji...@apache.org> on 2024/04/12 13:23:00 UTC
[jira] [Updated] (IGNITE-21805) Refactor TableManager and move all RAFT related pieces to Replica
[ https://issues.apache.org/jira/browse/IGNITE-21805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kirill Gusakov updated IGNITE-21805:
------------------------------------
Description:
*Motivation*
At the moment we have some places inside the TableManager, which:
* Use RaftManager to start/stop RAFT nodes (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
* Use RaftGroupService through table.internalTable().tableRaftService().partitionRaftGroupService calls
This fact prevents us on the track of zone-based collocation. The further collocation steps will be easier, if we will move the whole RAFT connected operation to the Replica class. Moreover, it should be there semantically
*Definition of done*
* All code inside the handleChangePendingAssignmentEvent connected with the start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and raft clients must be moved to the start of the Replica itself
* The same about handleChangeStableAssignmentEvent - the stop of Replica must stop appropriate raft node
* All calls for table.internalTable().tableRaftService().partitionRaftGroupService must be replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
*Implementation notes*
* The new temporary methods must be implemented and remove after IGNITE-22036:
**
{code:java}
// code placeholder
{code}
was:
*Motivation*
At the moment we have some places inside the TableManager, which:
* Use RaftManager to start/stop RAFT nodes
* Use RAFT clients for some rebalance activities
This fact prevents us on the track of zone-based collocation. The further collocation steps will be easier, if we will move the whole RAFT connected operation to the Replica class. Moreover, it should be there semantically
*Definition of done*
RAFT communication hidden under the Replica abstraction.
> Refactor TableManager and move all RAFT related pieces to Replica
> -----------------------------------------------------------------
>
> Key: IGNITE-21805
> URL: https://issues.apache.org/jira/browse/IGNITE-21805
> Project: Ignite
> Issue Type: Improvement
> Reporter: Kirill Gusakov
> Assignee: Mikhail Efremov
> Priority: Major
> Labels: ignite-3
>
> *Motivation*
> At the moment we have some places inside the TableManager, which:
> * Use RaftManager to start/stop RAFT nodes (handleChangePendingAssignmentEvent/handleChangeStableAssignmentEvent)
> * Use RaftGroupService through table.internalTable().tableRaftService().partitionRaftGroupService calls
> This fact prevents us on the track of zone-based collocation. The further collocation steps will be easier, if we will move the whole RAFT connected operation to the Replica class. Moreover, it should be there semantically
> *Definition of done*
> * All code inside the handleChangePendingAssignmentEvent connected with the start of raft groups (PartitionListener/RebalanceRaftGroupEventsListener) and raft clients must be moved to the start of the Replica itself
> * The same about handleChangeStableAssignmentEvent - the stop of Replica must stop appropriate raft node
> * All calls for table.internalTable().tableRaftService().partitionRaftGroupService must be replaced by the replicaMgr.replica(replicaGrpdId).raftClient()
> *Implementation notes*
> * The new temporary methods must be implemented and remove after IGNITE-22036:
> **
> {code:java}
> // code placeholder
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)