Info

If the AsyncRequestsSender is interrupted after sending one or more requests, it may not be able to gracefully cancel that request. establishCursors() has some cleanup logic to mitigate this, but I'm pretty sure that if we're interrupted then this line will also throw the interrupted error, and we won't be able to clean up our cursors.

Top User Comments

xgen-internal-githook commented on Wed, 6 May 2020 14:38:50 +0000: Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'} Message: SERVER-46255 Use killOperations to cleanup dangling remote requests (cherry picked from commit 93476f545de27ee61fd69eeab23adbff7f57b932) Branch: v4.4 https://github.com/mongodb/mongo/commit/cd42cb1a51f1e2a6c02759ad5fa1523b5b65faa9 xgen-internal-githook commented on Tue, 28 Apr 2020 18:40:57 +0000: Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'} Message: SERVER-46255 Use killOperations to cleanup dangling remote requests Branch: master https://github.com/mongodb/mongo/commit/93476f545de27ee61fd69eeab23adbff7f57b932 xgen-internal-githook commented on Tue, 28 Apr 2020 17:12:48 +0000: Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'} Message: Revert "SERVER-46255 Use killOperations to cleanup dangling remote requests" This reverts commit aa2e0ee6d817951a29f2fec33d374d13d8f46802. Branch: master https://github.com/mongodb/mongo/commit/49159e1cf859d21c767f6b582dd6e6b2d675808d xgen-internal-githook commented on Tue, 28 Apr 2020 13:34:48 +0000: Author: {'name': 'Nick Zolnierz', 'email': 'nicholas.zolnierz@mongodb.com', 'username': 'nzolnierzmdb'} Message: SERVER-46255 Use killOperations to cleanup dangling remote requests Branch: master https://github.com/mongodb/mongo/commit/aa2e0ee6d817951a29f2fec33d374d13d8f46802 nicholas.zolnierz commented on Thu, 5 Mar 2020 20:13:22 +0000: I've spent some time on this and haven't reached a fully robust solution, but some thoughts so far: I'm able to generate and propagate a unique opKey for sub-operations. If the cursor establishment is interrupted, its definitely possible to use this opKey in a _killOperations command. When the ARS is interrupted, there are several possible states for the remote requests: (1) The remote node is processing the command but has not yet established a cursor (2) The cursor has been established on the remote node and the response is in flight (3) The request hasn't reached the remote node yet From my understanding, the opKey/killOperations fix will handle (1) but not the other 2 scenarios. In fact, from testing, the likelihood of sending a killOperations command while the remote node is still processing the original request is far less than the (2) and (3). I'm looking into a potential workaround by extending killOperations to also lookup any cursors with the same opKey. jason.carey commented on Wed, 19 Feb 2020 19:55:18 +0000: See SERVER-44167 for more details on operation keys charlie.swanson commented on Wed, 19 Feb 2020 19:00:12 +0000: mira.carey@mongodb.com suggests that there is a new (or coming soon?) thing called OperationKey and killOperations that can help us here.

Steps to Reproduce