[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. |