[SERVER-22456] The oplog find query timeout is too low Created: 03/Feb/16 Updated: 19/Nov/16 Resolved: 03/Feb/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 3.2.0 |
| Fix Version/s: | 3.2.3, 3.3.2 |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | Scott Hernandez (Inactive) | Assignee: | Scott Hernandez (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | code-only | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Backport Completed: | |||||||||||||
| Participants: | |||||||||||||
| Description |
|
Due to a low timeout, it is possible that a mmap sync source will not be able to respond within the timeout (2s in PV0, and electionTimeout/2 = 5s by default). |
| Comments |
| Comment by Eric Milkie [ 10/Feb/16 ] |
|
You are mistaken; the comment in line 311 is correct description of the code. We only changed the timeout for issuing the original query. We intentionally did not change the timeout for advancing the cursor. |
| Comment by Scott Hernandez (Inactive) [ 10/Feb/16 ] |
|
What was done was intentional and only for the initial find portion, not the getmores, of the query. The timeouts are different due to liveness and heartbeat requirements for failover and elections. |
| Comment by Yoni Douek [ 10/Feb/16 ] |
|
Seems like you changed only one usage, but there are other places in code using 'fetcherMaxTimeMS' (in the callback + getmore?). |
| Comment by Githook User [ 03/Feb/16 ] |
|
Author: {u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: (cherry picked from commit d2a10dddb97cb8fa7b208661e1875d30fe796bba) |
| Comment by Githook User [ 03/Feb/16 ] |
|
Author: {u'username': u'scotthernandez', u'name': u'Scott Hernandez', u'email': u'scotthernandez@gmail.com'}Message: |