7f710a514a
If PoolCounter acquisition would block and a stale ParserCache entry is available, deliver it immediately rather than waiting for the lock. This should avoid PoolCounter contention on heavily edited pages. * Add a fastStale pool option to toggle the feature. False by default but I'll set the default to true in a followup commit. * Add a $timeout parameter to PoolCounter::acquireForMe() and acquireForAnyone(). This requires a simultaneous update to the PoolCounter extension. * In the Redis implementation, use the requested timeout for blPop() but use the configured timeout for data structure cleanup and item expiry. * Add a boolean $fast parameter to fallback() which tells the subclass whether it is being called in the fast or slow mode. No extensions in CodeSearch extend PoolCounterWork directly so this should not cause a fatal. * Pass through the $fast parameter in PoolCounterWorkViaCallback * In PoolWorkArticleView, use the $fast flag to decide whether to check the ChronologyProtector touched timestamp. * Add $wgCdnMaxageStale by analogy with $wgCdnMaxageLagged, which controls the CC:s-maxage when sending a stale ParserOutput. * Fix the documented type of the timeout. It really should be a float, but locks.c will treat non-integers as zero. A simultaneous update to the PoolCounter extension is required. Bug: T250248 Change-Id: I1f410cd5d83588e584b6d27d2e106465f0fad23e |
||
|---|---|---|
| .. | ||
| PoolCounter.php | ||
| PoolCounterNull.php | ||
| PoolCounterRedis.php | ||
| PoolCounterWork.php | ||
| PoolCounterWorkViaCallback.php | ||
| PoolWorkArticleView.php | ||