Details
-
Task
-
Resolution: Done
-
Major
-
7.6.0
-
None
-
0
Description
A number of bugs have been found in the usage of GlobalTask to manage both per-bucket (ep-engine) tasks and 'global' tasks not tied to a single bucket.
Specifically, GlobalTask has two different ctors, taking either a Taskable, or an EpEngine instance. The former (Taskable) ctor is intended when the Task is not associated with a specific bucket, and hence per-bucket memory tracking should not be performed. The latter (EpEngine) ctor is intended to be used for per-bucket tasks, and sets GlobalTask::engine to a non-null value.
However, it is relatively easy to call the "wrong" ctor - there's been two instances so far (MB-58576 and MB-59022) where the Tasable ctor was called for bucket-specific tasks and hence we did failed to track memory correctly.
Moreover, GlobalTask - while now part of the "server" part of KV-Engine, still includes ep-engine specific headers, as it needs to perform memory tracking operations for ep-engine instances.
For these reasons, we should restructure GlobalTask, moving the ep-engine specific functionality into a new EpTask subclass. This includes moving GlobalTask::engine member variable to EpTask, along with the corresponding ctor, making it more difficult to accidently call the wrong ctor. This also removes all of the "engines/ep" includes from GlobalTask, creating a cleaner separation of logic.
Attachments
Issue Links
- causes
-
MB-59806 Non-bucket specific stats (e.g. ExecutorPool::doTaskQStat) do not correctly account freed memory
- Closed
- relates to
-
MB-58576 StrictQuotaItemPager does not correctly account memory (de)allocations
- Closed
-
MB-59022 VBucketSyncWriteTimeoutTask does not correctly switch engine
- Closed
-
MB-59285 ItemFreqDecayerTaskManager incorrectly accounted to first created bucket
- Closed
-
MB-59286 Warmup::warmedUpVBuckets incorrectly accounts singleton memory to current bucket
- Closed