You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Alexei Scherbakov (Jira)" <ji...@apache.org> on 2019/10/28 07:07:00 UTC

[jira] [Resolved] (IGNITE-12327) Cross-cache tx is mapped on wrong primary when enlisted caches have incompatible assignments.

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

Alexei Scherbakov resolved IGNITE-12327.
----------------------------------------
    Resolution: Won't Fix

Already fixed in IGNITE-12038

> Cross-cache tx is mapped on wrong primary when enlisted caches have incompatible assignments.
> ---------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-12327
>                 URL: https://issues.apache.org/jira/browse/IGNITE-12327
>             Project: Ignite
>          Issue Type: Bug
>    Affects Versions: 2.7.6
>            Reporter: Alexei Scherbakov
>            Assignee: Alexei Scherbakov
>            Priority: Major
>             Fix For: 2.8
>
>
> This is happening when supplier node is left while rebalancing is partially completed on demander.
> Suppose we have 2 cache groups, rebalance is in progress and for first group rebalance is done and for second group rebalance is partially done (some partitions are still MOVING).
> At this moment supplier node dies and corresponding topology version is (N,0).
> New assignment is computed using current state of partitions and for first group will be ideal and the same as for next topology (N,1) which will be triggered after all rebalancing is completed by CacheAffinityChangeMessage.
> For second group affinity will not be ideal.
> If transaction is started while PME is in progress (N, 0)->(N,1), first lock request will pass remap check if it's enslists rebalanced group. All subsequent lock requests will use invalid topology from previous assignment.
> Possible fix: return actual locked topology version from first lock request and use it for all subsequent requests.



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