using one MemcachedClient per node in the cluster

I am using AWS clusters, but doing so in an unusual way. For my needs, scaling up and down is far burstier than most. That is, I go from 2 nodes to 8 or 8 nodes to 2. Therefore, consistent hashing doesn't help much. So what I want to do is on each of my java client machines that talk to the cluster, have one of your MemcachedClient classes for each node. Then there is no need for consistent hashing. What I am doing is this: when I scale up from 2 nodes to 8, I record that now the primary nodecount is 8 and the secondary node count is 2. When I do a get(), I first use my own murmur3 hash of the nodecount modules 8 to select the appropriate MemcachedClient to use, and if that fails, then my getter tries getting from nodecount modulus 2, and if found, adds it to the new primary node. Thus instead of consistent hashing, I pay the cost of 2 gets and a possible migration when the mapping is on the wrong node due to scale up.

The question to you is does your nio-based library handle the construction of many MemcachedClient objects, one per node, in a performant way, or did you design it to only work well with one MemcachedClient object for the entire cluster?

Start by reviewing the nio-based library's MemcachedClient construction and connection behavior for multiple client instances. Determine whether one client per cluster node is supported efficiently, and document the observed performance characteristics or limitations for the described AWS scaling pattern.

Written by the indexing model from the issue text.