Hi,
I'm almost asleep, so this might be terrible wrong, but who knows:
This is all based on the presumption that
$this->mMemc->get( $this->getOptionsKey( $article ) ); (in ParserCache)
returned false on Wikidata because the cache has been disable before or
whatever.
Then the problem is as follows:
One calls ParserCache::get() with $useOutdated=false (default value).
ParserCache::get calls out to ParserCache::getKey (with $useOutdated
still false).
That one then does: $this->mMemc->get( $this->getOptionsKey( $article )
).
If that returns false and $useOutdated is false also:
$usedOptions = ParserOptions::legacyOptions(); (line 152)
will be called which then nukes all our ParserOptions.
Cheers,
Marius
On Tue, 2013-12-10 at 21:45 +0100, Daniel Kinzler wrote:
> Hi.
>
> I (rather urgently) need some input from someone who understands how parser
> caching works. (Rob: please forward as appropriate).
>
> tl;dr:
>
> what is the intention behind the current implementation of
> ParserCache::getOptionsKey()? It's based on the page ID only, not taking into
> account any options. This seems to imply that all users share the same parser
> cache key, ignoring all options that may impact cached content. Is that
> correct/intended? If so, why all the trouble with ParserOutput::recordOption, etc?
>
>
> Background:
>
> We just tried to enable the use of the parser cache for wikidata, and it failed,
> resulting in page content being shown in random languages.
>
> I tried to split the parser cache by user language using
> ParserOutput:.recordOption to include userlang in the cache key. When tested
> locally, and also on our test system, that seemed to work fine (which seems
> strange now, looking at the code of getOptionsKey()).
>
> On the life site however, it failed.
>
> Judging by its name, getOptionsKey should generate a key that includes all
> options relevant to caching page content in the parser cache. But it seems it
> forces the same parser cache entry for all users. Is this intended?
>
>
> Possible fix:
>
> ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey,
> which could then be used to override the default behavior. Would that be a
> sensible approach?
>
> And if so, would it be feasible to push out such a change before the holidays?
>
> Thanks,
> Daniel
>
