[SERVER-21431] Sharding host targeting logic should use the remaining time from the OperationContext as a timeout Created: 12/Nov/15 Updated: 07/Feb/19 Resolved: 07/Feb/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | David Storch | Assignee: | Mathias Stearn |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Sprint: | Service Arch 2019-02-11 | ||||||||
| Participants: | |||||||||
| Description |
|
Currently RemoteCommandTargeter::selectFindHostMaxWaitTime() will always return a default timeout: https://github.com/mongodb/mongo/blob/master/src/mongo/client/remote_command_targeter.cpp#L48-L49 This is the timeout which we use when targeting a particular host within a shard. Instead of using a default, we should attach a timeout to the OperationContext (potentially the maxTimeMS value) and use this as the host targeting timeout. |
| Comments |
| Comment by Mathias Stearn [ 07/Feb/19 ] |
|
Fixed as of https://github.com/mongodb/mongo/commit/aa236ed4f3096c85118f00618eec834c82363527 |
| Comment by Kaloian Manassiev [ 01/Feb/19 ] |
|
redbeard0531, assigning this ticket to you to verify whether it is still applicable with your RSM work. If it is still needed, please put it on the backlog and leave it in the Epic. |
| Comment by David Storch [ 12/Nov/15 ] |
|
Done. |
| Comment by Spencer Brody (Inactive) [ 12/Nov/15 ] |
|
david.storch, can you add a description to this ticket to help us understand the impact and priority of this issue? |