Avoid having one wiki access another wiki's local keyspace.
Instead, use the global keyspace to share values across wikis.
Also, imitating wfMemcKey from wfForeignMemcKey was semantically
incorrect due to $wgCachePrefix having precedence. Most interfaces
(e.g. UserRightsProxy, FileRepo, JobQueue etc.) only have access
to the wiki id (dbname + prefix). The local cache configuration
for wgCachePrefix is not and shouldn't have to be exposed.
Start enforcing that local cache keys are left private and
to share keys, one must use global keys.
Global keys (prefixed with "global:") have their own space and we
can use the wiki-id as regular key segment for keys about users.
Also:
* Expose a method to keep formatting of this key in one place.
As it used used in many different places in core, as well
as in CentralAuth.
* Make use of wfWikiId() in getDefaultKeyspace() to avoid
duplicating this logic.
Change-Id: I58836a24b9e239f460ab489bd2fe8ced8259833c
This generally only effects wikis with no slave DBs,
but also matters if the master has non-zero LB load.
If the master ends up being used for DB_SLAVE, care
should be shown for cache-aside writes
Interesting WAN cache events are now logged.
Change-Id: I2cd8e84138263c13ea23beb9ab3d7562340e1fd3
Inject the DeferredUpdates::addCallableUpdate method via the
ObjectCache. This brings it closer to being able to move to /libs.
Change-Id: Ifa0d893002c3d709a4dc7346c263a92162274bd7
* Add a string `keyspace` member to BagOStuff instances. The default
implementation, meant for simple key/value stores, treats the key space
as a string prefix to prepend to keys. By default, its value is `local`,
but any instance created via ObjectCache::newFromParams() (or or one of
its callers) will have that default to $wgCachePrefix / wfWikiID().
* Add `makeKey` and `makeGlobalKey` methods to the base BagOStuff class.
These methods are not static to allow for BagOStuff types which require
a configured instance to know the underlying storage engine's key semantics.
* Make wfMemcKey() and wfGlobalCacheKey() delegate to these methods on the main
ObjectCache instance.
Change-Id: Ib7fc2f939be3decfa97f66af8c2431c51039905f
Provide a complement to ObjectCache::getMainWANInstance() and
ObjectCache::getMainStashInstance() which gets the default ObjectCache
instance.
Change-Id: Ib16ee40908b159e60be41a308db49a9291b5de0d
Because in PHP5.3:
php > $a = "hash";
php > echo isset( $a['fallback'] );
1
php > echo $a['fallback'];
h
This will fix using MediaWiki with MySQL on PHP5.3
if neither APC, xcache nor wincache are available.
Change-Id: Iebf034be75b282e2654cd298713455caf062eda4
There are imho too many ObjectCache methods, $wg*Cache* variables,
CACHE_ types, and wfGet*Cache() functions to know which ones
should actually be used publicly. This should make it easier to
know which ones should be used.
The difference between them was also harder to understand with the
main documentation sections about each of these living in
conceptually different places:
- classes (WANObjectCache)
- methods (ObjectCache::getMainStashInstance)
- variables (DefaultSettings: wgMainCacheType, wgMainWANCache, wgMainStash)
Also:
* Correct wfGetCache() documentation.
* Add the missing keywords for 'public' visibility.
Change-Id: I3b05fdb8b7888bf7e3f05bdca36538f3484556b8
* Whitespace.
* Simplify logic.
* Apply coding conventions to documentation blocks (empty line
before annotations, no empty lines between annotation, consistent
order of annotations).
Change-Id: I3e5268d6a6295643d5725c66ea2a01bccf610ed8
* This provides factory/config more appropriate for stashes
* Cleaned up some neighboring config comments while at it
Bug: T88493
Bug: T97620
Change-Id: Id370ee50be6e493a4700c858df863a183abc05fd
This class handles caching across distance sites where purges
must reach both. It also aims to make purging more reliable in
the face of network glitches and node consistent hash ejection.
bug: T88492
Change-Id: I686811b3075bf22e2f4de45127e8461e54648ead
Move the MWLogger PSR-3 logging related classes into the
MediaWiki\Logger namespace. Create shim classes to ease migration of
existing MWLoggerFactory usage to the namespaced classes.
Bug: T93406
Change-Id: I359cc81fbd2dcf8937742311dcc7d3dee08747b0
ObjectCache::newFromParams() will handle a 'loggroup' parameter
specially, getting an instance of \Psr\Log\LoggerInterface to
pass to the BagsOStuff.
BagOStuff implementations can use $this->logger which will be
an implementation of \Psr\Log\LoggerInterface. As this is set in
BagOStuff::__construct(), all subclasses must now call the
parent constructor.
The goal of this is to make the logging in BagOStuff non-MediaWiki
specific, in the hopes of separating it out into a separate library
in the future.
Change-Id: I8a8e278e6f028814499d8457d6d5341d03eabc7a
* This method is currently hit when bots use the maxlag API parameter
* Also added a $fallback param to ObjectCache::newAccelerator so code
does not have to keep reinventing that logic.
Change-Id: I45bf1085301c5cf69b29b494a146c6a067534581
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I86fd10e3f2d4bb80e7432533038d124693acfb3c
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
* Introduced a common base class for the two memcached clients, called
MemcachedBagOStuff.
* Moved the expiry time normalisation from MemcachedClient.php to
MemcachedBagOStuff since libmemcached needs the same workaround.
Change-Id: I507d4ec5a7fd863ae64a94f2c453981f9f03746c
As Brion points out in <https://bugzilla.wikimedia.org/show_bug.cgi?id=29747#c7>, the shared memory functions are very buggy. In fact, eAccelerator has disabled the shared memory functions by default for awhile now. I didn't touch APC, XCache or WinCache, but I imagine they suffer from the same problems.
Patch from John Du Hart: https://bugzilla.wikimedia.org/attachment.cgi?id=8849&action=diff
If XCache is present, but the xcache.var_size setting is off, we'll now consider it as xcache being disabled for CACHE_ACCEL purposes. It won't trigger view of the accelerator option in the installer, and at runtime if using CACHE_ACCEL and no other modules are available, it'll throw an error so you know that it doesn't work!
