[SERVER-49005] Improve concurrency testing for mongos cluster cursor manager Created: 22/Jun/20  Updated: 06/Dec/22

Status: Backlog
Project: Core Server
Component/s: Querying
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Ian Boros Assignee: Backlog - Query Execution
Resolution: Unresolved Votes: 0
Labels: qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-27796 Invariant failure in cluster_cursor_m... Closed
Assigned Teams:
Query Execution
Participants:

 Description   

SERVER-27796 (still unsolved) indicates that there may be a bug related to concurrency control in the cluster cursor manager. While we have a JS concurrency test (also this one) which target mongos cursor manager, the bug has never been reproduced in our own test environment.

 

We should consider adding a unit test which stresses the concurrency control of the cluster cursor manager directly, in similar spirit to d_concurrency_test, which directly stresses the mongod locking code with 32 threads. If the cause of SERVER-27796 is a concurrency control issue in the CCC, this would give us a better chance of reproducing it.

The existing JS test also runs with a mere 3 collections. The mongos code which triggers the invariant failure has to do with all cursors for a collection being destroyed, meaning that the JS test likely does not exercise this path very often. We should investigate whether this is indeed the case, and allow the test to run with more collections (assuming it won't make the existing workload useless) if so.


Generated at Thu Feb 08 05:18:40 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.