-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Networking, Sharding
-
None
-
Fully Compatible
-
ALL
-
v4.4
-
Query 2020-03-09, Query 2020-03-23, Query 2020-04-06, Query 2020-04-20, Query 2020-05-04
If the AsyncRequestsSender is interrupted after sending one or more requests, it may not be able to gracefully cancel that request. establishCursors() has some cleanup logic to mitigate this, but I'm pretty sure that if we're interrupted then this line will also throw the interrupted error, and we won't be able to clean up our cursors.
- depends on
-
SERVER-46767 Provide a mapping from OperationKey to CursorID
- Closed
- is related to
-
SERVER-48308 Avoid leaking exceptions in establishCursors cleanup callback
- Closed
-
SERVER-45541 Test killing an aggregation operation with a $unionWith stage
- Closed
-
SERVER-44167 Add OperationKey to OperationContext and allow "clientOperationKey" field with commands
- Closed
- related to
-
SERVER-65329 Ensure cursors are not leaked when cancelling in-progress operations
- Backlog
-
SERVER-46648 Cancel pending requests upon receiving the first response
- Closed
-
SERVER-46740 establishCursors() must always drain the AsyncRequestsSender::_baton
- Closed
-
SERVER-62710 AsyncRequestsMerger won't attempt to cleanup shard cursors when deadline is exceeded
- Closed
-
SERVER-50308 Adjust debug log message when cleaning up failed cursor establishment
- Closed
-
SERVER-47261 AsyncRequestSender should populate clientOperationKey
- Backlog