[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15329: --- Release Note: Improved `--consistency repair` command of the control.sh utility; atomic caches can now be repaired by Read Repair (was: Improved `--consistency repair` command of the control.sh utility; atomic caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov updated IGNITE-15329: --- Labels: iep-12 iep-31 ise (was: iep-12 iep-31) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31, ise > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-15329: -- Release Note: Improved `--consistency repair` command of the control.sh utility; atomic caches now repairable by Read Repair (was: Atomic caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Release Note: Atomic caches now repairable by Read Repair (was: Atomic. caches now repairable by Read Repair) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Release Note: Atomic. caches now repairable by Read Repair > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 4.5h > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15329: - Fix Version/s: 2.14 (was: 2.13) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Description: It's pretty clear that it's impossible to fix atomics with "Read Repair" atomically since it's impossible to lock entries during the repair process. Even get from backups has no guarantee to return consistent values under load. But to fix we must also perform an additional step - cache put. So, value can be changed between gets, can be changed after gets but before put, but it still seems to be possible to automize the fix. Idea is to decide what entry won on the last check attempt and put this value using the entry processor. During the entry processor execution, we should check the current node's value, and if the value is as it was during the check we must replace it with the consistent value. was: It's pretty clear that it's impossible to fix atomics with "Read Repair" atomically since it's impossible to lock entries during the repair process. Even get from backups has no guarantee to return consistent values under load. But to fix we must also perform an additional step - cache put. So, value can be changed between gets, can be changed after gets but before put, but it still seems to be possible to automize the fix. Idea is to decide what entry won on the last check attempt and put this value using the entry processor. During the entry processor execution, we should check the current node's value, and if the value is not expected for this node, we should perform put, but record a concurrent modification event. > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is as it was during the check we must replace it with > the consistent value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Labels: iep-12 iep-31 (was: iep-31) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-12, iep-31 > Fix For: 2.13 > > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is not expected for this node, we should perform put, > but record a concurrent modification event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Fix Version/s: 2.13 > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.13 > > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is not expected for this node, we should perform put, > but record a concurrent modification event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Labels: iep-31 (was: ) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is not expected for this node, we should perform put, > but record a concurrent modification event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15329) Atomics should be repairable by Read Repair
[ https://issues.apache.org/jira/browse/IGNITE-15329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-15329: -- Parent: IGNITE-15167 Issue Type: Sub-task (was: Improvement) > Atomics should be repairable by Read Repair > --- > > Key: IGNITE-15329 > URL: https://issues.apache.org/jira/browse/IGNITE-15329 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > > It's pretty clear that it's impossible to fix atomics with "Read Repair" > atomically since it's impossible to lock entries during the repair process. > Even get from backups has no guarantee to return consistent values under load. > But to fix we must also perform an additional step - cache put. > So, value can be changed between gets, can be changed after gets but before > put, but it still seems to be possible to automize the fix. > Idea is to decide what entry won on the last check attempt and put this value > using the entry processor. > During the entry processor execution, we should check the current node's > value, and if the value is not expected for this node, we should perform put, > but record a concurrent modification event. -- This message was sent by Atlassian Jira (v8.3.4#803005)
