[SERVER-28090] Add ability to interrupt operations using pinned cursors on mongos Created: 23/Feb/17  Updated: 20/Feb/18  Resolved: 14/Feb/18

Status: Closed
Project: Core Server
Component/s: Querying, Sharding
Affects Version/s: 3.5.3
Fix Version/s: 3.7.3

Type: Improvement Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Ian Boros
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-32307 Make AsyncResultsMerger kill sequence... Closed
is depended on by SERVER-6496 provide a way to kill a sharded query... Closed
Related
is related to SERVER-21710 Allow pinned ClientCursors to be kill... Closed
Backwards Compatibility: Fully Compatible
Sprint: Query 2018-02-12, Query 2018-02-26
Participants:

 Description   

If killCursor is called on the cursor, it is marked as "killPending", and later reaped by the periodic ClusterCleanupCursorJob.

"Reaping" the ClusterClientCursor sends killCursors to all shards that have cursors on them as part of this sharded query.

Currently, only one thread can use a ClusterClientCursor at a time, because the cursor must be "checked out" of the ClusterCursorManager to be used. This means if killCursor is called on the cursor while the cursor in use by a thread, the cursor is not killed by the reap thread until the first thread has finished getting a round of results from it and checked it back in.

It would be preferable if it was possible to "interrupt" the ClusterClientCursor from the reap thread, by interrupting the operation which is using the cursor's operation context.

This would mean the first thread would stop scheduling further requests to get results, and just wait for outstanding responses to return. This is much better than waiting for the entire round of results to complete.

Currently, the AsyncResultsMerger (ARM) kind of supports being killed from a second thread: on ARM::kill(), it stops scheduling further requests as described above. However, if the thread doing kill() destroys the ClusterClientCursor after kill() returns, the first thread will have a reference to (and perhaps try to use) an invalid ClusterClientCursor, including an invalid ARM.

The work in SERVER-27937, which splits the ClusterClientCursor's implementation into a CursorEstablisher and ARM, will mean the first thread may have a reference to an invalid CursorEstablisher or invalid ARM.

kaloian.manassiev



 Comments   
Comment by Githook User [ 13/Feb/18 ]

Author:

{'email': 'ian.boros@10gen.com', 'name': 'Ian Boros'}

Message: SERVER-28090 add ability to interrupt pinned cursors on mongos
Branch: master
https://github.com/mongodb/mongo/commit/30e5dded30c373f9519e4c5347f7a92a9fa2d59f

Comment by Charlie Swanson [ 12/Jan/18 ]

This should be unblocked by SERVER-32307

Comment by David Storch [ 07/Mar/17 ]

After discussing with esha.maharishi, I'm going to mark this ticket as a dependency of SERVER-6496, which tracks the work required to kill sharded read operations easily across all shards. Ensuring that we can interrupt query execution of a mongos cursor in a timely fashion, rather than waiting until outstanding batches from the shards have been received over the network, is a required part of this work. Waiting for batches from the shards is not acceptable in sharded kill, as the this could take an arbitrarily long amount of time (e.g. a long-running query might be running).

Similarly, we must make it possible to kill an in-use cursor on mongod. The mongod-side work is tracked by SERVER-21710, which is linked as related to this ticket.

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