[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: |
|
||||||||
| 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: |
| Comment by Githook User [ 22/May/23 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: |
| Comment by Githook User [ 17/May/23 ] |
|
Author: {'name': 'George Wangensteen', 'email': 'george.wangensteen@mongodb.com', 'username': 'gewa24'}Message: |
| 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. |