[SERVER-39475] Support socket disconnect kills for getMore Created: 08/Feb/19  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Internal Code
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Mira Carey Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 1
Labels: PM-1279, former-quick-wins
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Query Execution
Backwards Compatibility: Fully Compatible
Participants:

 Description   

As part of the socket disconnect project, a new facility (OperationContext::markKillOnClientDisconnect) was introduced which, when invoked, makes the operation treat socket disconnect as a kill thereafter.

The litmus test for whether to flag an opctx this way is supposed to be whether the underlying operation is idempotent. I.e. if someone from the outside could have detected if it suceeded or failed if they had connected, started running their command, saw it in currentop, then killed the socket (and gotten full value from the command).

For most cursors, this is a no brainer, if you die while reading a batch, we usually close the cursor. There's some complexity around detecting whether a cursor is secretely a $out agg cursor that was initiated with batchSize 0 however. In that case, we'd like to avoid applying the flag.



 Comments   
Comment by Charlie Swanson [ 04/Apr/19 ]

Noticed this was '4.1 Desired' but not attached to anything that would cause us to do it for 4.2. Flagging for scheduling to discuss if it's worth an effort to make that happen.

Generated at Thu Feb 08 04:52:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.