rishabhdaim commented on PR #3071: URL: https://github.com/apache/jackrabbit-oak/pull/3071#issuecomment-5243690160
@joerghoh, thanks for the review. However, the PR is still not ready for review and has gaps that need to be addressed. > When the cache maintenance runs in its own thread, what is the impact on the other threads (interactive requests with a focus on low latency) be? > > because this > > > so HTTP request threads serving pages ran full cache maintenance mid-request and slowed all concurrent segment-cache operations on the pod. > > makes me think, that no matter which thread performs this maintenance, there will always be an impact on other threads which are accessing that cache concurrently. And that this change will just speed up the (request) thread, which ran all the maintenance and therefor incurred a massive latency on that particular [Oak-repository](https://issues.apache.org/jira/browse/OAK-repository) operation. > > Is my understanding correct? **AI (Claude Analysis)** You're right that the work itself doesn't vanish; it just moves to the 2-4 dedicated maintenance threads. But it's not true that other threads feel the same pain either way. Caffeine normally grabs its eviction lock with tryLock() — if it's busy, the caller just backs off instantly, no waiting. That lock is meant to be held for microseconds, just long enough to hand the cleanup work off to an executor. The bug here was that with executor(Runnable::run), "handing it off" actually meant running the whole cleanup — including our removal listeners, which do real work like persistent-cache writes — while still holding that lock. If that drags on and Caffeine's write buffer fills up in the meantime, other writer threads stop being polite about it — they fall back to a blocking lock() call and just wait. That's exactly where the "excessive wait times acquiring the eviction lock" warning comes from: several threads queued up behind one slow one. So this isn't about shifting cost from one thread to another — it's about no longer holding that lock long enough for a queue of other threads to build up behind it. That's what was actually causing the stalls and the wedge. One caveat: if the maintenance pool itself gets swamped, we do fall back to running inline again (CallerRunsPolicy) — but only the thread that triggered it pays for that, nobody else gets stuck waiting on it. -- 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]
