[
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)