When CDRIVER-2857 introduced the mongoc_client_reset() method, it added logic to mongoc_cursor_destroy() that skipped two actions if the client generation differed:
- Disconnect the socket for an active exhaust cursor
- Send a killCursors command for an active, normal cursor
At the time, mongoc_client_reset() also disconnected all nodes in the cluster, so the fact that mongoc_cursor_destroy() did not disconnect the socket for an active exhaust cursor was not important.
CDRIVER-3116 later changed mongoc_client_reset() such that sockets are left alone. I believe this means that users of exhaust cursors will no way of avoiding an error in a child process when attempting to re-use a socket from a parent that previously opened an exhaust cursor.
This may not be a significant issue, as our take-away from PHPC-1274 was that mongoc_client_reset() was mainly useful as a means to prevent children from destroying cursors owned by a parent and/or re-using session IDs from a parent. There was not stated goal of allowing a child process to continue using sockets from a parent's client, and I believe doing so would likely lead to an out-of-sequence wire protocol error since processes might read each other's responses unexpectedly.
Having said that, I'm curious if we should allow mongoc_cursor_destroy() to still disconnect a socket for an active exhaust cursor regardless of the client's generation.
- is related to
-
CDRIVER-3116 Do not disconnect sockets in mongoc_client_reset()
- Closed
-
CDRIVER-2857 Provide a reset method to be called on clients after forking
- Closed
-
PHPC-1274 Reset libmongoc client after forking to avoid interacting with parent resources in child processes
- Closed
- related to
-
CDRIVER-3487 Exhaust cursors on single threaded drivers may interfere with SDAM monitoring
- Backlog