I believe that this paragraph describes what you want to see:
Updating partition mapping
It is important for client to keep partition mapping updated. To ensure this, the following changes are proposed:
Changes in Standard Message Response header. It is proposed to add flag to every response, that shows whether the Affinity Topology Version of the cluster has changed since the last request from the client.
If the Affinity Topology Version of the cluster has changed since the last request from the client, new Affinity Topology Version is also included in the response.
Once client detects changes in the Affinity Topology, it does the following:
Updates distributionMap and partitionMap (preferably asynchronously) for all active caches. It also may be done "on demand" - on the first call to the Cache instance;
Tries to establish connection to hosts, which is not yet connected. This is required as changes of the topology may be caused by the new node joining the cluster.
Not sure my understanding is correct or not.
There is the case when a new node join a cluster, if it's just as your said
then some key can not get directly from *the new added node*
I suppose it would work as below.
1: 5 node cluster(a,b,c,d,e)
2: even I just set two nodes/endpoints in the client configuration. upon the
first successfully hand-shark, the response should return all the nodes with
IP in the cluster.
3: clients try to connect other server node.
if the client just connect to the specified nodes/endpoints then for the
other un-specified nodes. it still need
an additional net hop.
what's more even I can specified all the server nodes in advance. then how the handle the case for adding a new server node? Need to stop the client and restart again?