priyeshkaratha commented on PR #11187: URL: https://github.com/apache/ozone/pull/11187#issuecomment-6195099485
> Hmm. The new locking can stall SCM requests until the Ratis timeout. > > The add and remove paths hold the buffer read lock while waiting for a synchronous Ratis reply. If the flush monitor queues for the write lock before the applier acquires its read lock, the caller waits for the applier, the monitor waits for the caller, and the applier waits behind the monitor. Progress resumes only after the request times out—30 seconds by default. > > Please avoid holding the buffer lock across the synchronous Ratis call while preserving protection against the summary reload race. A regression test should go through the HA proxy; the current tests call the implementation directly and miss this lock cycle. Thanks, the lock cycle was real: the caller waited for the applier, the flush monitor waited for the caller, and the applier waited behind the monitor until the 30s timeout. The caller no longer holds the buffer lock across the synchronous Ratis call, which breaks the cycle. The reload race is still guarded by summaryLock, inFlightOps and the atomic flush-and-reload on becoming leader. Details are in the thread replies above. I also removed an unused test hook and aligned the SCMHADBTransactionBufferStub.flushAndRun implementation with the real buffer. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
