[
https://issues.apache.org/jira/browse/IGNITE-22689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17871631#comment-17871631
]
Kirill Gusakov edited comment on IGNITE-22689 at 8/7/24 1:58 PM:
-----------------------------------------------------------------
The tricky part of the implementation: support the correct and synchronized
behaviour between the:
* Local events listener inside the TableManager (for table state machines
creating).
* Catalog events listeners insde the TableManager (for tables creating).
For this purpose after some discussions we decided to implement the
TableManager inner state based approach, where local events will always work in
the context of current TableManager tables list instead of the catalog version
context. This mechanism must be reused in the drop behaviour for free
IGNITE-22950. IGNITE-22956 was created as a result of these investigations
was (Author: kgusakov):
The tricky part of the implementation: support the correct and synchronized
behaviour between the:
* Local events listener inside the TableManager (for table state machines
creating).
* Catalog events listeners insde the TableManager (for tables creating).
For this purpose after some discussions we decided to implement the
TableManager inner state based approach, where local events will always work in
the context of current TableManager tables list instead of the catalog version
context. This mechanism must be reused in the drop behaviour for free
IGNITE-22950
> Investigate the mechanism for loading table processors on zone replicas start
> and table creation
> ------------------------------------------------------------------------------------------------
>
> Key: IGNITE-22689
> URL: https://issues.apache.org/jira/browse/IGNITE-22689
> Project: Ignite
> Issue Type: Improvement
> Reporter: Kirill Gusakov
> Assignee: Kirill Gusakov
> Priority: Major
> Labels: ignite-3
>
> *Motivation*
> At the moment, table manager listens the assignments changes and then create
> the partition state machines. In the case of zone-based replication, this
> approach is artificial. Tables should know nothing about the assignments now
> and use the events from PartitionReplicaLifecycleManager instead, to initiate
> the process of partition creation/drop in the case of rebalance, for example.
> *Definition of done*
> Prepare the working algorithm, which satisfy the following flow:
> - PartitionReplicaLifecycleManager fire the events about the zone replica
> create.
> - TableManager listens these events and create target partition
> - At the same time TableManager listens the table creation from catalog and
> load the needed state machines to the zone replicas. All possible races must
> produce correct result.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
