This lets callers use adaptive TTLs on the near-expiration
preemptive refreshes if the new and current values match,
using the as-of time as $mtime.
Change-Id: Ie541c35f890c9f789d1accf9f2a43506daaf31f0
This lets callers have their own process cache but keep it
managed in a central location, making it easier to reset
when DB transaction snapshot are flushed or when unit tests
want to clear caches between runs.
Use this to replace the Revision text process cache.
Change-Id: Ic61ee9140d4ce9836cc4650adb5bb75a291fea18
Callers using wfTimestamp( TS_UNIX, ... ) where getting $minTTL
due to the output being a string number.
Change-Id: I6b67a941940f40ef9a543f11d0dbccacafaaa53b
* This better handles delayed/lost cache purges by
having lower TTLs for entries that often changes.
* Use this for foreign upload description page caches,
we purges are never received from the source wiki.
* Also use this for User and LocalFile cache TTLs.
* Also move the Database::getCacheSetOptions() call in
User *before* doing the queries, which is preferred.
* Fixed some IDEA errors too, like the undeclared
mApiBase field.
Change-Id: I70f8ebb29ac853c2a530d9eedb9e7facc1b7b710
* Update documentation about relay methods.
* Change interim key set() to add() to avoid broadcasting it.
* Remove the behavior of doing purges synchronously in the
local DC first before relay. In both the event relayer and
mcrouter case, they will be asynchronous. It was hardly
even possible to use such behavior since loads come from
slave DBs, which do not see changes right after COMMIT.
Bug: T97562
Change-Id: I7759c82ae6e1b72fc227882a99c9a712a46374f6
This can change the TTL without fetching the object
so that keys can be renewed or set to expire soon.
Change-Id: Id1c2c9f89b3445cfa34263057dc5029cbe170833
This is useful for avoiding stampedes in the one case that lockTSE
does not alone cover, which is when the key does not exist or is
tombstoned.
Also avoid saving interim values unless the key is tombstoned
since there is no point in doing that otherwise.
Change-Id: I70997e90217a0979e0589afa7a5107b0e623c7cf
* getWithSetCallback() takes a 'version' parameter.
* If the value at a key has a different version, then
getWithSetCallback() will automatically use a separate
key. Which value "wins" the main key does not matter.
* Purges are handled by using the main key as a sort of
check key (with no hold-off). Note that this key is always
purged on delete().
* Changed stash keys to track the same info as other keys
both for consistency and because this change needs the
generation timestamp. Renamed the stash prefix to avoid
corrupt results with Het Deploy.
* This is useful for things like the User class that use
versioning and have cross-wiki key access and purges.
Currently, bumps to version must be deployed to all wikis
at once, which this aims to avoid.
Change-Id: I26ae62f116e32b48bcf06bc13f8b9e79ae976745
Add new 'reportDupes' parameter to BagOStuff. This parameter enables scheduling
of a callback after the current web request ends. This callback will emit warning
log messages for all keys that were requested more than once.
The default ObjectCache factory for MediaWiki enables this option by default.
Not by default for plain BagOStuff instances, however. E.g. `new HashBagOStuff()`.
It also set 'asyncHandler' for all classes now (not just MultiWriteBagOStuff).
Bug: T128125
Co-Authored-By: Timo Tijhof <krinklemail@gmail.com>
Change-Id: I8a2b06cf54d2acf5950eed71756ecdf50e224be1
Ie161e0f was done in a hurry, and so didn't do things in the best ways.
This introduces a new "CachedBagOStuff" that transparently handles all
the logic that had been copy-pasted all over in Ie161e0f.
The differences between CachedBagOStuff and MultiWriteBagOStuff are:
* CachedBagOStuff supports only one "backend".
* There's a flag for writes to only go to the in-memory cache.
* The in-memory cache is always updated.
* Locks go to the backend cache (with MultiWriteBagOStuff, it would wind
up going to the HashBagOStuff used for the in-memory cache).
Change-Id: Iea494729bd2e8c6c5ab8facf4c241232e31e8215
* This can happen due to incr/add races. Use incrWithInit()
instead to handle such cases.
* Also made BagOStuff:incrWithInit() return the new value like incr().
Change-Id: I0e3b02a4cff7c20544a9db2eaabd3f61e5a470b1
If a set() happened around the exact same time as check key was
initialized via get(), the curTTL in future get() calls could
sometimes be 0 instead of a negative value, even though hold-off
should apply.
Change-Id: Ide1fd65112aff425a4798e2ec406d71f2a8e84a7
To allow batch queries for multiple keys that themselves have different check
keys. Previously check keys always applied to all keys being retrieved.
Change-Id: I9e5ba198d79020ce05a802a510762e29fcfb2f1b
* Match behaviour of MapCacheLRU and ProcessCacheLRU.
* Add missing unit tests for TTL and maxCacheKeys eviction behaviour.
Change-Id: I559eae1cd336274b21728e86775cfbad7e2f2c6d
Follows-up 7cddc22.
Also use PHPUnit_Framework_TestCase as parent instead of MediaWikiTestCase
in preparation for library extraction.
Change-Id: I0e68e56ecf8376b52a59c33ba6dd18b671bdcfc9
* Keys that take a long time to generate would run into
the MAX_SNAPSHOT_LAG check and have set() no-op. This
would be fine except that leaves no key there to figure
out the time since expiry and therefore whether to use
the mutex, so it didn't. This now saves the keys but with
a FLG_STALE bit set, making the next caller that sees it
perform a regeneration (unless it can't get the mutex).
* Bumped LOCK_TTL so that keys can stay locked much longer.
* This is easy to test via sleep(5) in tagUsageStatistics()
and two Special:Tags browser tabs.
Bug: T91535
Change-Id: I549e70ace3d2e7da40d3c4346ebacc36024cd522
* In the common ~0 second lag case, transactions up to ~7 seconds
long will have normal set() behavior (instead of just ~5 seconds).
* Like wise with ~0 second transactions tolerating ~7 seconds of
lag (instead of just ~5).
* The lower hold-off time lets caching resume 3 seconds sooner.
Change-Id: I21e2a0a6915492cec422b6a6af5541937745c15b
