[SERVER-65938] Collection haveCappedWaiters should check actual waiters, not potential waiters Created: 25/Apr/22  Updated: 13/Jun/22  Resolved: 13/Jun/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Matthew Russotto Assignee: Matthew Russotto
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-59776 50% regression in single multi-update Closed
Sprint: Repl 2022-05-02, Repl 2022-05-16, Repl 2022-05-30, Repl 2022-06-13, Repl 2022-06-27
Participants:

 Description   

Background:

The Collection method haveCappedWaiter()s returns whether anyone has a shared pointer to the collection's cappedNotifier. Some time in the 3.6 timeframe (SERVER-29127), we started holding the cappedNotifier whenever we were in an oplog find/getMore even when we were not actually waiting for data, because holding the cappedNotifier also allows us to track the notifier version. However, haveCappedWaiters() is used for oplog visibility; specifically, if we have capped waiters, we update oplog visibility immediately (and ping the capped notifier) rather than batch notifications. This should only happen if someone is waiting on the notifier, not if they are merely tracking it.

Solution: We should maintain the version on the capped notifier whenever anyone has a shared pointer to it. But we should return true from haveCappedWaiters only if the notifier is actually in the wait loop.


Generated at Thu Feb 08 06:04:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.