Details
-
Bug
-
Resolution: Fixed
-
Major
-
7.6.0, 7.0.0-Beta1, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.4, 7.0.5, 7.1.0, 7.1.1, 7.1.2, 7.2.0, 7.1.3, 7.2.1, 7.1.5, 7.2.4, 7.2.2, 7.1.6, 7.2.3, 7.2.5, 7.6.1
-
Untriaged
-
0
-
Unknown
-
March-June 24
Description
We've seen DCP_STREAM_REQUEST execute slowly and a suspect was the StreamContainer data structure which is used twice per request
1) A look-up (does a stream already exist) - read-lock only
2) An insert (new stream placed in map) - write-lock
In a same set of logs we see a slow-runtime for ActiveStreamCheckpointProcessorTask just before a bunch of DCP_STREAM_REQUESTS are released (also logging as slow).
The logs in question showed a CBAS workload reconnecting, which is a heavy user of the stream-id feature which means a stream-container can hold many objects.
I suspect that alongside maybe some large checkpoints the read-lock is held for quite sometime - although in the logs we see a 17 second runtime for the stream processor which is worrying, that would have to be a huge checkpoint.
However it's clear that the ActiveStreamCheckpointProcessorTask should not keep a read-lock whilst processing all of the streams, it should copy the ActiveStream (shared_ptr) and drop the lock then process.
Suspect all collection releases affected, will check.
Attachments
Issue Links
- relates to
-
MB-62141 ActiveStreamCheckpointProcessorTask long runtimes possible when using stream-id
- Closed