[SERVER-36062] Mobile SE: Stop running parallel and concurrent suites on mobile variants Created: 11/Jul/18 Updated: 29/Oct/23 Resolved: 25/Jul/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Storage |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.2, 4.1.2 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Sulabh Mahajan | Assignee: | Sulabh Mahajan |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Backport Requested: |
v4.0
|
||||||||
| Sprint: | Storage Non-NYC 2018-07-16, Storage Engines 2018-07-30 | ||||||||
| Participants: | |||||||||
| Linked BF Score: | 0 | ||||||||
| Description |
|
parallel, parallel_compatibility, concurrency and concurrency_simultaneous test suites are not adding much to the coverage for mobile while adding to the time it takes to run the variants. Mobile SE is not intended to run parallel and concurrent operations and hence running these suites over it isn't building confidence in it's stability any more than the other core tests. For instance, on RHEL 6.2 (mobile), following are the runtimes during my trial runs when excluding map_reduce tests ( |
| Comments |
| Comment by Githook User [ 07/Aug/18 ] |
|
Author: {'username': 'sulabhM', 'name': 'Sulabh Mahajan', 'email': 'sulabh.mahajan@mongodb.com'}Message: (cherry picked from commit f165a6aac867472f38bd0d6f52fcf39e2be17ce6) |
| Comment by Sulabh Mahajan [ 25/Jul/18 ] |
|
We had a meeting to discuss this ticket and it was decided to do the following:
|
| Comment by Githook User [ 25/Jul/18 ] |
|
Author: {'name': 'Sulabh Mahajan', 'email': 'sulabh.mahajan@mongodb.com', 'username': 'sulabhM'}Message: |
| Comment by Max Hirschhorn [ 13/Jul/18 ] |
|
Just because today's implementation of concurrency of the mobile storage engine matches what SQLite expects doesn't mean that we won't accidentally break it in the future. We're currently depending on a handful of tests that use startParallelShell() and the jstestfuzz_concurrent suite to find any futures issues when using multiple clients. Are we confident that those tests / test suites are sufficient enough to have caught the problematic behavior we'd seen before with SQLite? |
| Comment by Andrew Morrow (Inactive) [ 12/Jul/18 ] |
|
Thanks sulabh.mahajan, that sounds reasonable. |
| Comment by Sulabh Mahajan [ 12/Jul/18 ] |
|
acm,
Yes, the locking model is different, so the testing requirements are lower. The concurrent/parallel operations (unless just reads) end up being serialised by the lock manager. Hence, I believe that beyond lock manager, we are only testing mobile under the same scenarios that other test suites should have already done, while greatly increasing the testing time and resources consumed. Here are my reasons why we shouldn't run these suites on mobile:
Note: I don't know time taken for parallel and parallel_compatibility, because basic and basicPlus are ignoring the tags on the tests and I haven't been able to run with these tests turned on. I end up running and failing on capped collection/profiling tests. |
| Comment by Andrew Morrow (Inactive) [ 11/Jul/18 ] |
|
Can you clarify a bit what you mean about "not intended to run parallel and concurrent operations"? The invoking application can certainly have multiple threads "connected" to embedded that are executing concurrent database operations. Or are you saying that it doesn't matter given the locking model of the underlying storage engine in use? |