-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor - P4
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Replication
-
ALL
-
-
Repl 2025-12-22, Repl 2026-01-05, Repl 2026-01-19
-
None
-
None
-
None
-
None
-
None
-
None
-
None
After changing replWriterThreadCount and replWriterMinThreadCount to be settable at runtime (see PR), there can now be a concurrent issue when trying to update both params in parallel.
Scenario leading to a crash:
Let's imagine a scenario where the current min (replWriterMinThreadCount) is 8 and the current max (replWriterThreadCount) is 12.
If a user concurrently updates the min and max to be 2 and 4. We can end up in a bad situation where the following happens in this order:
- validateUpdateReplWriterMinThreadCount() is called first and succeeds
- replWriterMinThreadCount is updated to 2, but before onUpdateReplWriterMinThreadCount() is called the other thread updating replWriterThreadCount executes.
- validateUpdateReplWriterThreadCount() is called, it succeeds
- replWriterThreadCount is updated and onUpdateReplWriterThreadCount() is called, the thread pool max count is updated before the min count is updated => crash (here)!
Potential fixes:
We should add a mutex protecting the validation and setting of the replWriterThreadCount and replWriterMinThreadCount params, so that we don't end up with two clients setting these concurrently and ending up with bad values. We could take the lock during the validateXXX, and release it in the onUpdateXXX.
Or another solution would be to make replWriterMinThreadCount only settable at startup, this way we don't have this issue. But we would still need to make replWriterThreadCount atomic. (like this example)
- is related to
-
SERVER-108740 Be able to change oplog applier thread count without restarting the node
-
- Closed
-