[jira] [Issue Comment Deleted] (IGNITE-11936) Avoid changing AffinityTopologyVersion on a server node join/left event from not baseline topology.

["Alexey Goncharuk (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-11936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexey Goncharuk updated IGNITE-11936:
--------------------------------------
    Comment: was deleted

(was: [~NSAmelchev], [~avinogradov], a few comments for the PR:
 * The {{localRecoveryNeeded}} does not seem right - you check the list of partitions from affinity assignment cache. There may be a case when a node still owns a partition, but it is not an assigned backup for this partition (this will happen right after late affinity assignment change, when affinity cache is changed to an ideal assignment, but the node did not yet RENTed a partition). In this case, the partition will not be reported in the list of partitions and recovery will be skipped
 * Do I understand correctly that *all* new transactions will still wait for this optimized PME to complete? If yes, what is the actual time boost that this change gives? Do you have any benchmark numbers? If no, how do you order transactions on a new primary node with the backup transactions on the same node that did not finish recovery yet?)

> Avoid changing AffinityTopologyVersion on a server node join/left event from not baseline topology.
> ---------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-11936
>                 URL: https://issues.apache.org/jira/browse/IGNITE-11936
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Amelchev Nikita
>            Assignee: Amelchev Nikita
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, a client join/left event does not change AffinityTopologyVersion (see IGNITE-9558). It shouldn't be changed on a server node join/left event from not baseline topology too.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)