[SERVER-77085] MultipleCursorsGetMoreWorks TaskExecutorCursorTest Should Allow getMores on cursors to occur in either order Created: 12/May/23  Updated: 29/Oct/23  Resolved: 17/May/23

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 7.1.0-rc0, 6.0.7, 7.0.0-rc2

Type: Bug Priority: Major - P3
Reporter: George Wangensteen Assignee: George Wangensteen
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Depends
Assigned Teams:
Service Arch
Backwards Compatibility: Fully Compatible
Operating System: ALL
Backport Requested:
v7.0, v6.0
Sprint: Service Arch 2023-05-29
Participants:
Linked BF Score: 22

 Description   

When TaskExecutorCursor receives a multi-cursor response to the remote, and pre-fetching is enabled, it schedules getMores on each cursor: one via the current TaskExecutorCursor, and one via the constructors of each new TaskExecutorCursor it creates to handle the additional responses (see the call to processResponse here for the first cursor's getMore, and the call to processResponse here for the getMores for each additional cursor created.

These getMores can reach the network in any order. However, the MultipleCursorsGetMoreWorks test expects a particular ordering of the getMores reaching the network. Before connection-pinning was enabled, this was fine, because the network mocking infrastructure for the non-pinning case is guaranteed to receive the requests in the order they are scheduled by the TaskExecutorCursor response-processing thread. However, the mocking infrastructure for the pinning case is more like the "real" network, in that it can receive these requests out-of-order.

We should fix the test to be resilient to the getMores for each of the multiple cursors arriving at the network in any order.



 Comments   
Comment by Githook User [ 23/May/23 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-77085 Ensure PinnedConnectionTaskExecutor sends requests to the network in the order they were scheduled.
Branch: v6.0
https://github.com/mongodb/mongo/commit/b61660734527b5e1f2aa00851fe65d7563146775

Comment by Githook User [ 22/May/23 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-77085 Ensure PinnedConnectionTaskExecutor sends requests to the network in the order they were scheduled.
Branch: v7.0
https://github.com/mongodb/mongo/commit/9534bb72994cc3ee9ad2f8bf78266220ba376c53

Comment by Githook User [ 17/May/23 ]

Author:

{'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}

Message: SERVER-77085 Ensure PinnedConnectionTaskExecutor sends requests to the network in the order they were scheduled.
Branch: master
https://github.com/mongodb/mongo/commit/17ecec00ebe6f1bbb5f78bb94021292789dd5a35

Comment by George Wangensteen [ 16/May/23 ]

It's a bit challenging to improve the mocking infrastructure to be resilient to the cursors arriving in either order. Instead, I think we should take advantage of the fact that the TaskExecutorCursor is guaranteed to schedule the getMore for cursor 1 before it schedules the getMore for cursor 2. Improving the PinnedConnectionTaskExecutor to execute requests in the ordered they are scheduled is trivial, which means that we can guarantee that the request for cursor 1 reaches the network before the request for cursor 2. This fixes the problem because it allows the test to continue to rely on this ordering.  

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