[SERVER-50305] ARS::next() does not respect OperationContext deadline Created: 13/Aug/20 Updated: 29/Oct/23 Resolved: 09/Feb/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.23 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matthew Saltz (Inactive) | Assignee: | Benjamin Caimano (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | apm-issue, sharding-wfbf-day | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Sharding 2020-08-24, Security 2021-01-25, Security 2021-02-08, Security 2021-02-22 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
In 4.0, AsyncRequestsSender::next() can end up calling _scheduleRequests, which eventually tries to do shard targeting in a blocking manner. This deadline in shard targeting should be updated to be the minimum of the current deadline and the deadline set on the OperationContext, so that clients aren't accidentally blocked if targeting takes a long time. We should also add a deadline to this call to Baton::run. |
| Comments |
| Comment by Matthew Saltz (Inactive) [ 24/Aug/20 ] |
|
|