-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Correctness
Currently, we have two implementations of background hooks:
- A simple implementation that works with jscore / jstestfuzz but is incompatible with FSM workloads
- A complex implementation that works with all types of workloads, including FSM workloads
The hooks obviously differ in terms of logic to be executed in the background (for example initial sync vs. config transitions), but a most of the hook's complexity comes from (re)writing code that synchronizes the hook's thread with the rest of Resmoke / with FSM workloads. It would be great if all this complexity could be abstracted away.
BGHook attempted to provide this abstraction for the simple implementation, but was only adopted by one hook. So we have a few hooks that are copies of the simple implementation: 1, 2, 3, etc.
And meanwhile there exists no template for the complex implementation, and so we have eight hooks that are copies of the complex implementation: 1, 2, 3, 4, 5, (and the recently deleted tenant migration hooks) 6, 7, 8. Note that not all of them use the FileBasedThreadLifecycle object (ex 3), 6), 7), 8) don't). And 3) incorrectly used only the FlagBasedThreadLifecycle type (see SERVER-95248 for context) when it should've been able to use both.
Having multiple copies of the same implementation makes bug fixes harder to do, because the it needs to be applied repeatedly in sometimes a non-obvious way (example bug with complex implementation: SERVER-60595).
Note: this is related to, but not the same as SERVER-95380 / SERVER-95379.
- is related to
-
SERVER-60595 Resmoke hooks such as ContinuousTenantMigration may not pause even after being paused
- Backlog
-
SERVER-95379 Get rid of TestData.useActionPermittedFile
- Needs Scheduling
-
SERVER-95380 Abstract away ThreadLifecycle object and get rid of the is_fsm_workload / use_action_permitted_file variable
- Needs Scheduling