* Also added getBlob() and getBlobs() methods. These don't
require passing ResourceLoader as argument.
In preparation for T113092.
Change-Id: I3239c45f0243eca1eaf85bc53fca736e4c9a209c
The $ucfirst and $wgContentLang variables are not used by get().
Keep these inside getMessageFromFallbackChain() instead.
Also add mark getMsgFromNamespace() as public since it is used
in other places in core and by extensions.
Change-Id: I83bf77c17aa46f3929f89c4af97693611761629b
* Update and improve class documentation.
* Remove comment that claims to return false if the module has no message.
generateMessageBlob() returns '{}' in that case. And this is expected since
we want to cache the absence of messages.
* Re-use the module objects passed to MessageBlobStore::get() in getFromDB()
instead of using ResourceLoader::getModule(). The object is the same either
way (since ResourceLoader re-uses the objects also) but reduces complexity
of getFromDB() to not need the ResourceLoader object as parameter.
Change-Id: I89a14d7185877fae52791f6837883ed3a6749cd7
Language::ucfirst() already has this optimisation. The expensive
method is Language::uc(), which is only called when needed.
The ord() < 128 is one of the conditionals in Language::ucfirst().
Change-Id: Idd648b7b84eba1f92dda904438122fe38d3cf22b
Follows-up af89b09a06 and e40a90f0bc, and general phasing out
of MapCacheLRU and ProcessCacheLRU.
Use of ProcessCacheLRU seems redundant in this case as it is
essentially just a keyed singleton.
Change-Id: I7cc84cf6c76ecc422ea337dba2d216c3d7ebf281
In preparation for conversion from MapCacheLRU to HashBagOStuff.
* Use early-return pattern for error and rejection cases.
* Add 'int' to @return for getGoodLinkFieldObj() per the
values set in addGoodLinkObj().
* Add type hints for Title where possible.
* Avoid single-letter variables like $f and $s.
* Add visibility for public static methods.
Change-Id: Iab90539922f648c21cb147f749943a64f598e8de
* This avoids throwing atomic section errors when recache()
is triggered in the middle of transactions.
* Also made the read-only checks handle $wgReadOnly mode.
Change-Id: Ie00cf8454656a6dc3b1862475a959b2af3b472f0
This table is not needed because module names and their messages
array are available to the runtime environment at very little cost.
The only purpose it was serving is reverse lookup from message
key to module name (e.g. when MessageCache receives update that
need to propagate to MessageBlobStore). However that is better
achieved by simply looping through modules in PHP. The overhead
of a database is not worth this minor convenience.
MessageBlobStore
* insertMessageBlob: Doesn't need to update msg_resource_links.
* updateModule: Doesn't need to update msg_resource_links.
* getUpdatesForMessage: Reimplement with list from memory
instead of msg_resource_links.
The database table will be removed in If009e2620e59002e1.
Bug: T113092
Change-Id: Ia9131f570001f00c9800b260ac4b3469d54d2784
When the LocalisationCache class is set to 'detect', we prefer LCStoreCDB if
$wgCacheDirectory is set, but we default to LCStoreDB otherwise. Rather than
give up, we should try wfTempDir(), since any directory that meets its criteria
is also suitable for LCStoreCDB.
Change-Id: Id3e2d2b18ddb423647bf2e893bcf942722c0e097
Deprecated since MediaWiki 1.26 (32d1017e7d). These methods contain the
only remaining callers of MapCacheLRU::getAllKeys() which is the only odd
method of MapCacheLRU not supported by BagOStuff.
Change-Id: I64e054803595d49a5bd779accc94353924f7d87d
The $mForUpdate flag no longer causes the FOR UPDATE option to be added.
This was at first only true for some values of $wgAntiLockFlags (since
r9248 / ba8a00bcb833), though since 12757b50f8 (when the setting was
removed), is always the case.
The added text is based on the description for $wgAntiLockFlags.
Change-Id: I02a3e2df37ec40c7e36ae6210c8263f13d9e3e5b
CacheEpoch isn't meant for this (it's meant for page cache), I can't
imagine a scenario in which we'd want to bump that to invalidate
MessageBlobStore. It should be standalone and can be easily cleared
if needed by truncating the relevant table (it's automatically
repopulated).
This also removes wfTimestamp/DateTime overhead.
Change-Id: Iab06edbf71f20f3430207a80df90131c79dc03a7
These callers don't need to do purges, but can still perfectly
take advantage of this instance over a plain BagOStuff. Namely:
* Replication and snapshot lag awareness
* Preemptive regeneration
* Easy process cache support
The idea is for there to only be one caching class/factory
to use, instead of having rules for picking which one to use.
Change-Id: I8e362df451c0c28731fc853c044c4c4b8e097f01
LocalisationCache was added in 1.16, so in order to retain PHP 5.1
compatibility, array_fill_keys() was avoided. In 1.17, support for
PHP 5.1 was dropped, so we can use that function now.
Change-Id: I435705639f1a470324a4ba46153351aadc0d40e2
* If replace() was called recently, then we know that this is the
master data center and that the messages are up-to-date. With this
change, replace() calls have nothing to contend with aside from other
replace() calls. Even if there were timeouts due to such contention,
caused by high MediaWiki: page edit rates, the replace() updates would
pick up the prior changes in passing since they do load().
* This also avoids the following scenario:
a) Someone edits a message page, triggering replace()
b) Some page view causes load() to trigger loadFromDB()
due to the hash being seen as volatile due to replace()
c) The loadFromDB() loads stale slave data and undoes
the message key update the replace() did
Change-Id: I9cdf7ad3d67f168fcba7f633af9e32a8d1fa928e
* Made the status key only act as a backoff key inside
loadFromDBWithLock(), instead of also being a lock key. The
getReentrantScopedLock() call is now non-blocking, which has
a similar affect to the add() call on the status key but much
better prioritizes replace(); that method already has a blocking
getReentrantScopedLock() call, so once it gets that lock, there
is no worry of load() failing due to contention.
* Bail out in loadFromDBWithLock() if the scope lock was not acquired.
Normally the status lock often assured the lock could be obtained,
unless a competing replace() came in. The old status lock would
cause a bail if not acquired, and this carries over that behavior
but also avoids clobbering updates when replace() contention happens.
* Avoid calling saveToCaches() in replace() if the lock was not
acquired to avoid clobbering conflicting writes.
* Made the loadFromDB() call in replace() use DB_MASTER to avoid
seeing stale data if the cache is volatile.
* Lowered WAIT_SEC, as the default PHP timeout is 30.
We want this to be able to at least finish the other calls
in replace() even if the lock times out.
* Avoid checking the status key an extra time in load().
* Made a few small code and doc cleanups.
Change-Id: Ibaf1f67618ec374c83c3135a71e90223dd2b1856
* The key salting of the invidial keys via the WAN cache makes
it OK to use slaves here. The salting happens via the delete()
in the MessageCache::replace() call, which is hit when the
message page is edited.
Bug: T92357
Change-Id: Ic191f6c3fc49c4c58461d26468dd0fa94a52051e
* These keys are used for larger messages not in the main blob,
and they still use explicit purges as the pages change
Change-Id: I254ddcc9ffe7c49654788d6aabcca2ab7ed4f03f
* The localCache member will use CACHE_NONE if this is off,
so the set()/get() calls are already no-oped
* Also allow using the local cache if $hash is false
in "stale mode", which handles the case where the hash
key fell out of memory for some reason more gracefully
Change-Id: Ie12efcd4088a6dc4a4cdd2fd06646f2881df53d7
* This avoids constant churn when $wgUseLocalMessageCache is set to false
* Follow up to db464b8a84
Bug: T109183
Change-Id: I8da324c53527da32d09964be6c3a92176af4ee7b
Follow-up for I020617d, where I got this wrong. It is probable that multiple
application servers will try to build a local cache at the same time, in which
case they will cause the cache key to thrash. It is necessary that two
application servers building a local cache from the database generate the same
hash for a given set of messages.
Change-Id: Ieeefc2094a83be9401c466bec859c1588ddfbcdf
* Use hash key volatility to propagate invalidations over DCs
in addition to memcached->APC instances.
* Make use of stale APC cache due to hash mismatch instead
of waiting around in some cases. This is similar to the
TTL expiry and volatility cases.
* Renamed $hashExpired and added some comments for clarity.
Change-Id: I8890fb174cae72c4ce8872df64f52f5cbd55183b
In addition to eliminating disk IO in a hot path, using APC spares us from
having to serialize and unserialize cache arrays. Since we're not serializing,
though, we don't have a string representation to hash, so use a random string
instead. (The code already treats the association of hash string to cache as
purely symbolic, so this is not problematic.)
Whereas the hash was previously stored as the first 32 bytes of each cache
file, we now store it as an array key instead (like VERSION and EXPIRY were
already). Because this changes the structure of cached data, we have to bump
MSG_CACHE_VERSION.
While we're here, make MessageCache::getLocalCache() and
MessageCache::saveToLocal() protected, make their signatures more
consistent with other methods in this class. While they were (implicitly)
public before, there are absolutely no external callers in Core or
extensions[0][1], so we can skip the standard deprecation process.
[0]: https://github.com/search?q=%40wikimedia+getlocalcache&type=Code&utf8=%E2%9C%93
[1]: https://github.com/search?utf8=%E2%9C%93&q=%40wikimedia+savetolocal&type=Code
Change-Id: I020617d2df2a8f0f243b85f3383dc7b16f15aaad
Especially in long running maintenance scripts, this can be problematic.
LinkCache is now LRU-based, and will store a maximum of 10,000 good titles,
and 10,000 bad ones.
LinkCache::getGoodLinks() and getBadLinks() are deprecated since they
problematic to support in this implementation and are unused.
Bug: T106998
Change-Id: I1328149d65a5e75a5d6e10cb2686a099562a1847
Missing global declaration when using $wgContLang in
MessageCache::normalizeKey
Change-Id: Ia1c1f41244fd5629527b99a5f2038f607cff42c4
Follow-up: 47e0f0c3
