[
https://issues.apache.org/jira/browse/IGNITE-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451186#comment-17451186
]
Anton Vinogradov commented on IGNITE-15316:
-------------------------------------------
It's a good idea to consider a replacement (as a part of this issue)
{noformat}
for (KeyCacheObject key : keys) {
List<ClusterNode> nodes = ctx.affinity().nodesByKey(key,
topVer); // affinity
primaryNodes.put(key, nodes.get(0));
...
{noformat}
to
{noformat}
for (KeyCacheObject key : keys) {
List<ClusterNode> nodes = ctx.topology().nodes(key.partition(),
topVer); // topology
primaryNodes.put(key, nodes.get(0));
...
{noformat}
at
{{org.apache.ignite.internal.processors.cache.distributed.near.consistency.GridNearReadRepairAbstractFuture#map}}.
This may help to reduce remaps count at unstable topology, but require being
thoughtfully researched.
> Read Repair may see inconsistent entry at tx cache when it is consistent but
> updated right before the check
> -----------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-15316
> URL: https://issues.apache.org/jira/browse/IGNITE-15316
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
>
> Even at FULL_SYNC mode stale reads are possible from backups after the lock
> is obtained by "Read Repair" tx.
> This is possible because (at previous tx) entry becomes unlocked on primary
> before tx committed on backups.
> This is not a critical problem for Ignite in general but produces false
> positive "inconsistency state found" events and repairs.
> Unlock relocation does not seems to be a proper fix, since it will cause a
> performance drop.
> So, we should recheck values several times if an inconsistency is found, even
> when the lock is already obtained by "Read Repair".
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
