[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:
Depends
depends on SERVER-46740 establishCursors() must always drain ... Closed
Related
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:

 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 ]

SERVER-46740 must be done first to prevent an invariant from being hit when the deadline on Baton::run expires

Generated at Thu Feb 08 05:22:19 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.