Loading...

XML

Word

Printable

JSON

Type: Bug
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 4.4.0-rc4, 4.7.0
Affects Version/s: None
Component/s: Networking, Sharding
Labels:
None

Backwards Compatibility:
Fully Compatible
Operating System:
ALL
Backport Requested:

v4.4
Sprint:
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 hedging reads

Open

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

Open

(5 related to)

Assignee:: Nicholas Zolnierz

Reporter:: Charlie Swanson

Participants:: Charlie Swanson, Githook User, Mira Carey, Nicholas Zolnierz

Votes:: 0 Vote for this issue

Watchers:: 5 Start watching this issue

Created:: Feb 19 2020 06:53:15 PM UTC

Updated:: Jan 08 2024 03:22:58 PM UTC

Resolved:: Apr 28 2020 07:37:12 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates