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 > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
