[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13265: Fix Version/s: 2.9.1 > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10, 2.9.1 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov updated IGNITE-13265: Fix Version/s: (was: 2.9.1) > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-13265: --- Reviewer: Alexey Scherbakov > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-13265: --- Description: On a historical rebalance some updates move from one node to another wherein this update may have various order in nodes. Reordering can happen in smell interval, but it cannot avoid at all in current implementation atomic protocol. This mean we will reduce a probably of loosing update if we make a margin from initial counter for the historical iterator on atomic cache. The final algorithm of choosing correct WAL pointer for atomic cache with the margin is: 1) Find a checkpoint which contains a counter, that necessary for history rebalance (just like a transactional cache) 2) If the checkpoint starts with a counter less than which is necessary with margin, we are taking it. 3) If we are going out of WAL reservation, we are taking current. 4) Otherwise we are looking of a previous checkpoint and taking it if it starts from a counter less than next checkpoint (from the point 2). 5) Else we are still taking the checkpoint from the point 2. Other words (points 3-5) the algorithm tries to check only one previous checkpoint and takes it if that has different counter. *UPD:* After a discussion I found a bug connected with using a WAL which was not reserved before for preloading. I added an explicitly checking this and an appropriate test. was: On a historical rebalance some updates move from one node to another wherein this update may have various order in nodes. Reordering can happen in smell interval, but it cannot avoid at all in current implementation atomic protocol. This mean we will reduce a probably of loosing update if we make a margin from initial counter for the historical iterator on atomic cache. > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Time Spent: 2h 10m > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13265: - Fix Version/s: 2.10 > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.10 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required
[ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-13265: - Labels: 2.9.1-rc (was: ) > Historical iterator for atomic group should transfer few more rows than > required > > > Key: IGNITE-13265 > URL: https://issues.apache.org/jira/browse/IGNITE-13265 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: 2.9.1-rc > Fix For: 2.10 > > Time Spent: 3.5h > Remaining Estimate: 0h > > On a historical rebalance some updates move from one node to another wherein > this update may have various order in nodes. Reordering can happen in smell > interval, but it cannot avoid at all in current implementation atomic > protocol. > This mean we will reduce a probably of loosing update if we make a margin > from initial counter for the historical iterator on atomic cache. > The final algorithm of choosing correct WAL pointer for atomic cache with the > margin is: > 1) Find a checkpoint which contains a counter, that necessary for history > rebalance (just like a transactional cache) > 2) If the checkpoint starts with a counter less than which is necessary with > margin, we are taking it. > 3) If we are going out of WAL reservation, we are taking current. > 4) Otherwise we are looking of a previous checkpoint and taking it if it > starts from a counter less than next checkpoint (from the point 2). > 5) Else we are still taking the checkpoint from the point 2. > Other words (points 3-5) the algorithm tries to check only one previous > checkpoint and takes it if that has different counter. > *UPD:* > After a discussion I found a bug connected with using a WAL which was not > reserved before for preloading. > I added an explicitly checking this and an appropriate test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
