Thanks for responding Brion. Hopefully this has highlighted something that
is fundamentally misunderstood with the caching code. For the short term
maybe we could use better documentation, and the long term would be a fix
on the task you have created.
Anyways I am now using CACHE_DB :)
Regards,
Nischay
On Apr 4, 2017 12:29 AM, "Brion Vibber" <bvibber(a)wikimedia.org> wrote:
I've filed a task in phabricator to follow up in case there's any surprises
with the proposed fix. :)
https://phabricator.wikimedia.org/T162077
-- brion
On Mon, Apr 3, 2017 at 11:52 AM, Brion Vibber <bvibber(a)wikimedia.org> wrote:
On Mon, Apr 3, 2017 at 12:56 AM, Nischay Nahata
<nischayn22(a)gmail.com>
wrote:
>
> I have been trying to add certain rate limiting actions for my
extension's
API and
noticed that it doesn't work with $wgMainCacheType set to
CACHE_NONE
This is because User::pingLimiter()
uses ObjectCache::getLocalClusterInstance() to store the current rate
limit
counts.
Is this the expected behavior? Looks pretty deceitful to me
as $wgMainCacheType is assumed to define the cache type but is actually
disabling a core functionality like rate limiting and maybe few others?
I'm pretty sure this one's my fault -- at the time it was added we didn't
expect the rate limit feature to be used in a minimal configuration
without
an object cache configured, and it ended up being kind
of kept that way
through the years.
I would recommend probably changing this:
$cache = ObjectCache::getLocalClusterInstance();
to:
$cache = ObjectCache::getInstance( CACHE_ANYTHING );
That should set the rate limiter to use the database-backed cache when
$wgMainCacheType is set to CACHE_NONE, and will use the main cache when
it's not set off.
-- brion
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l