[SERVER-46684] Repackage the hang-analyzer as a resmoke subcommand Created: 06/Mar/20 Updated: 29/Oct/23 Resolved: 07/May/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 4.2.7, 4.4.0-rc4 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Vlad Rachev (Inactive) | Assignee: | Raiden Worley (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | tig-hanganalyzer, tig-resmoke | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.4, v4.2
|
||||||||||||
| Sprint: | STM 2020-05-04, STM 2020-05-18 | ||||||||||||
| Participants: | |||||||||||||
| Story Points: | 2 | ||||||||||||
| Description |
The exact syntax will need to be fleshed out, but the new command should at least be able to accept pids and process_types for backwards compatibility. |
| Comments |
| Comment by Githook User [ 05/May/20 ] |
|
Author: {'name': 'Carl Raiden Worley', 'email': 'carl.worley@10gen.com', 'username': 'aggrand'}Message: |
| Comment by Githook User [ 04/May/20 ] |
|
Author: {'name': 'Carl Raiden Worley', 'email': 'carl.worley@10gen.com', 'username': 'aggrand'}Message: |
| Comment by Githook User [ 04/May/20 ] |
|
Author: {'name': 'Carl Raiden Worley', 'email': 'carl.worley@10gen.com', 'username': 'aggrand'}Message: |
| Comment by Raiden Worley (Inactive) [ 21/Apr/20 ] |
|
Just a thought on this ticket: The hang analyzer has a few components (parser, process lister class for each OS, dumper for each OS, debug extractor, a bunch of helper functions). The parser stuff will almost definitely need to be integrated with the rest of resmoke's parsing as part of this ticket, but I also think it'd help readability to have the process listers and dumpers and debug extractor broken into separate files in a directory of resmokelib, maybe with listers and dumpers inheriting from an ABC describing the interface. The existing classes are already decently modularized and have similar interfaces so I don't think that'll be too much extra effort. |