Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-65938

Collection haveCappedWaiters should check actual waiters, not potential waiters

    • Type: Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Priority: Icon: Major - P3 Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Labels:
    • Repl 2022-05-02, Repl 2022-05-16, Repl 2022-05-30, Repl 2022-06-13, Repl 2022-06-27


      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.

            matthew.russotto@mongodb.com Matthew Russotto
            matthew.russotto@mongodb.com Matthew Russotto
            0 Vote for this issue
            4 Start watching this issue