[SERVER-9654] Increased tolerance around network connectivity issues in findN Created: 13/May/13 Updated: 10/Dec/14 Resolved: 13/May/13 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code, Networking |
| Affects Version/s: | 2.4.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | David Hows | Assignee: | Unassigned |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Operating System: | ALL | ||||
| Participants: | |||||
| Description |
|
Investigate making "DBClientBase::findN" more tolerant regarding network connectivity issues during execution, i.e. investigate the possibility of a fresh TCP connection to resume the findN as opposed to simply asserting. Most interprocess communications use this function to issue calls to another MongoD, this includes Sharding, Replication and initial syncing. If we can make this function (or somewhere on this code path) more tolerant to errors than we reduce the impacts of a flaky network connection on clients. |
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 13/May/13 ] |
|
findN should not be doing retries. |