[CDRIVER-1893] localThresholdMS calculated in microseconds Created: 01/Nov/16  Updated: 07/Nov/16  Resolved: 02/Nov/16

Status: Closed
Project: C Driver
Component/s: libmongoc
Affects Version/s: 1.2.0
Fix Version/s: 1.5.0

Type: Bug Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: A. Jesse Jiryu Davis
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to CDRIVER-1639 Rand used to pick Mongo server is not... Closed

 Description   

This was discovered while reading the code. The topology scanner sets each server's round trip time in microseconds, then compares the round trip time to localThresholdMS, which is specified in milliseconds (default 15ms).

In theory, this means that when the driver is doing secondary reads, it ignores a member that is even 15 microseconds higher-latency than the nearest secondary.

In practice, I believe the behavior is this: the driver always reads from the lowest-latency member matching the read preference, instead of the specified behavior of reading from the lowest-latency member and all members not more than 15ms higher-latency. But in many users' replica sets, secondaries have similar latencies. Which secondary is lowest-latency varies from one scan to the next, so the driver accidentally distributes reads reasonably evenly.



 Comments   
Comment by Githook User [ 02/Nov/16 ]

Author:

{u'username': u'ajdavis', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@mongodb.com'}

Message: CDRIVER-1893 localThresholdMS calc'ed in usec

This was discovered while reading the code. The topology scanner sets each
server's round trip time in microseconds, then compares the round trip time to
localThresholdMS, which is specified in milliseconds (default 15ms).

In theory, this means that when the driver is doing secondary reads, it ignores
a member that is even 15 microseconds higher-latency than the nearest
secondary.

In practice, I believe the behavior is this: the driver always reads from the
lowest-latency member matching the read preference, instead of the specified
behavior of reading from the lowest-latency member and all members not more
than 15ms higher-latency. But in many users' replica sets, secondaries have
similar latencies. Which secondary is lowest-latency varies from one scan to
the next, so the driver accidentally distributes reads reasonably evenly.
Branch: master
https://github.com/mongodb/mongo-c-driver/commit/d6d06fe4b50f95d573749842f16a09a141fb5bed

Generated at Wed Feb 07 21:13:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.