[ https://issues.apache.org/jira/browse/IGNITE-5357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16174686#comment-16174686 ]
Mikhail Lipkovich edited comment on IGNITE-5357 at 9/21/17 12:53 PM: --------------------------------------------------------------------- Hi Alexei, I'm working on this task but I faced with one question which I can't resolve. I found the piece of code that as I understand should be updated to resolve the task. But there is a {{canRemap}} flag which has an unclear meaning for me. Please find below method {{GridPartitionedSingleGetFuture#affinityNode}}: {code} if (!canRemap) { for (ClusterNode node : affNodes) { if (cctx.discovery().alive(node)) return node; } return null; } else return affNodes.get(0); {code} It's commented that {{canRemap}} is a flag indicating that get should be done on a locked topology version but it's not clear for me how it is related to the piece of code above. Should I somehow take care about this flag during implementation of requested functionality or I can just ignore it? Thanks was (Author: mlipkovich): Hi Alexei, I'm working on this task but I faced with one question which I can't resolve. I found the piece of code that should be updated. But there is a {{canRemap}} flag which has an unclear meaning for me. Please find below method {{GridPartitionedSingleGetFuture#affinityNode}}: {code} if (!canRemap) { for (ClusterNode node : affNodes) { if (cctx.discovery().alive(node)) return node; } return null; } else return affNodes.get(0); {code} It's commented that {{canRemap}} is a flag indicating that get should be done on a locked topology version but it's not clear for me how it is related to the piece of code above. Should I somehow take care about this flag during implementation of requested functionality or I can just ignore it? Thanks > Replicated cache reads load balancing. > -------------------------------------- > > Key: IGNITE-5357 > URL: https://issues.apache.org/jira/browse/IGNITE-5357 > Project: Ignite > Issue Type: Bug > Components: cache > Affects Versions: 1.6 > Reporter: Alexei Scherbakov > Assignee: Mikhail Lipkovich > Labels: newbie > Fix For: 2.3 > > > Currently all read requests from client node to replicated cache will go > through primary node for key. > Need to select random affinity node in topology and send request here (only > if readFromBackups=true) > If where are server nodes collocated on same host with client, must select > target node from them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)