[
https://issues.apache.org/jira/browse/IGNITE-15316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17451186#comment-17451186
]
Anton Vinogradov edited comment on IGNITE-15316 at 12/6/21, 2:58 PM:
---------------------------------------------------------------------
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.
Looks like affinity mapping instead of topology may cause unchecked copies on
unstable topology.
was (Author: av):
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)
