Hi, thanks for your contribution! Unfortunately we cannot accept it. The way secondary_acceptable_latency_ms is currently implemented is our intended behavior. Please see my explanation of the algorithm here:

http://emptysqua.re/blog/reading-from-mongodb-replica-sets-with-pymongo/

In brief: your patch means we only read from the lowest-latency member. But we intend to distribute load among any replica set members that are within 15ms of the lowest-latency member.

Hi, @ajdavis when I saw the code, I can understand the purpose.

I have 3 nodes in a set, to a web server(W1), the ping time is: 0.1ms(N1), 20ms(N2), 20ms(N3).

The read_preference = ReadPreference.NEAREST in connection.

When N1 is down, that will make W1 can't work, because no valid node in the set will return (for read). If set secondary_acceptable_latency_ms>20, the performance is not acceptable to W1.

I think load balance or hit the real nearest should be an option, but in current pymongo, it can't be done.

Hi, I understand your concern.

If N1 is down, then MongoReplicaSetClient discovers that N1 is down the next time it tries to use it:

clone_with_host_down() removes N1 from the list of usable nodes. So the next time you do a query, 20ms is the lowest latency among the nodes that are up. The MongoReplicaSetClient will use N2 and N3 equally with "NEAREST" read preference.

The next time the MongoReplicaSetClient's monitor thread wakes it will check if N1 has come up. If it has, N1 is returned to the list of usable nodes.

So your idea of "real nearest" is actually what I implemented.

Your idea of "load balance" can be achieved if you set secondary_acceptable_latency_ms very high, like 10000ms. Then the MongoReplicaSetClient will read equally from all nodes regardless of latency:

MongoReplicaSetClient(
    hosts='N1,N2',
    replicaSet='set_name',
    read_preference=ReadPreference.NEAREST,
    secondary_acceptable_latency_ms=10000)