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