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