-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
(copied to CRM)
-
Minor Change
As a result of PYTHON-799, cursors are added to a queue upon closure and killCursors on their IDs are issued periodically in the background. In cases where an uniterated cursor is queued for closure shortly before termination (for instance, in a signal handler), the process can exit before the next execution of the periodic cleanup thread, leaving open cursors on the server. This can have negative consequences in e.g. a sharded cluster, where open cursors can block chunk migrations. The latter problem is worsened in cases where customers have increased the server-side cursorTimeoutMillis for operational reasons.
A minimal reproduction script is attached, which quite reliably leaves a cursor open on the server after termination as shown below. Tests were conducted with pymongo 3.4.0 on a 3.4.3 replica set and sharded cluster.
> db.serverStatus().metrics.cursor { "timedOut" : NumberLong(0), "open" : { "noTimeout" : NumberLong(0), "pinned" : NumberLong(0), "total" : NumberLong(1) } }
Sleeping for a few seconds after closing the cursor avoids this issue, as does adding one final execution of the cleanup function after the join in the periodic executor's exit handler. Registering a custom CursorManager to close the cursors synchronously also prevents orphaned cursors, although I believe that this approach would again be susceptible to PYTHON-799.
Thanks!
Bernard
- causes
-
PYTHON-2092 MongoClient.close may create new connections
- Closed
- is related to
-
PYTHON-1353 Explicitly closed CommandCursors may not be killed before termination
- Closed