Page MenuHomePhabricator

reports of caching issues
Closed, ResolvedPublic

Description

Author: mathias.schindler

Description:
http://notes.computernotizen.de/2012/07/31/hat-die-wikipedia-ein-caching-problem/ is reporting about caching issues. Pages of outdated versions are shown.


Version: unspecified
Severity: normal
Whiteboard: aklapper-moreinfo
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=43341
https://bugzilla.wikimedia.org/show_bug.cgi?id=41130
https://bugzilla.wikimedia.org/show_bug.cgi?id=48927

Details

Reference
bz38879

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:46 AM
bzimport set Reference to bz38879.
bzimport added a subscriber: Unknown Object (MLST).

wikizilla wrote:

Logged in I got the most recent version of the article, logged out I got a version that was more than a month old.

The article was purged now manually. But it's not a singular occasion, so the reason why the caching failed could be important to find the bigger problem.

Sounds like the issue with % encoded url vs. 'utf-8 urls'. Only one of the url types is purged, and depending on your browser type, you could end up at one of the other types.

This is bug 27935

The article was purged now manually. But it's not a singular occasion, so the
reason why the caching failed could be important to find the bigger problem.

Purged manually how (?action=purge on the article page?). If hartman's suggestion is correct, that sort of manual purge shouldn't affect things [you could have the old page just fall out of cache at the same time by coincidence though]

wikizilla wrote:

Bawolff: Yes, purged by the ?action=purge-command.

Can someone look into the logs, what exactly happened with the specific article on the caching servers in Amsterdam? de:Europäischer Tag des Fahrrades

Just to easily verify if the theory in comment 3 is correct or not, what is the precise url of the page in question. (Including the % encodings as used).

Personally I think this might just be a case of a cache purge packet got lost somewhere along the way (assuming that this is a one-off event)

(In reply to comment #5)

Bawolff: Yes, purged by the ?action=purge-command.

Can someone look into the logs, what exactly happened with the specific article
on the caching servers in Amsterdam? de:Europäischer Tag des Fahrrades

Honestly I somewhat doubt such log files exist (they would be huge). In any case I personally (being a random) don't have access, one would have to ask the ops folks.

Mathias / wikizilla: Could you please provide the exact URL of an affected page? (Including the % encodings as used).

mathias.schindler wrote:

No. Torsten Kleinz maybe.

Someone on Wikipedia (on WP:VPT) was just complaining about the squid cache of http://en.wikipedia.org/wiki/Golden_rule being outdated (Note that that is a redirect to Golden_Rule). Last week (It is fixed now) I noticed that WP:SIGNPOST cache was outdated (That is the redirect [[WP:SIGNPOST]] not the real [[Wikipedia:The Signpost]]. Perhaps there is a problem with purging squid cache of redirect pages. [There was a bug about a year ago about redirects not being squid purged that was never really tracked down, and didn't appear locally - bug 29552 ]

Some more testing:

To pick a random redirect - I used [[WP:VPT]] (Since it gets edited a lot).

Downloading from N. America (not logged in obviously) at ~16:30 utc:

*I get a page last editing (according to the html comment) on 12 December 2012 at 05:54. That's 51 revisions that each should have sent purges to that redirect, but did not.

Downloading from Europe (using the 91.198.174.225 en.wikipedia.org in /etc/hosts trick to pretend I live in europe) things get a lot worse:

*The page I get has a last edited timestamp of 3 December 2012 at 21:30. That's 460 revisions which each should have triggered a purge, but none did.


Additionally there's been several reports of images not being purged by squid cache. This is more noticeable since logged in users get the squid version (but in a way less, because it is less common to do image reuploads, which is what is effected). [This is mostly bug 41130]
*?action=purge the image description page does not appear to be purging the squid cache of thumbnails. It should be.
*On re-upload, the old thumbnail is not being purged. There have been several reports of this in several places. For example: https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=84940049#Problem_with_new_version_of_image as while as a recent message to wikitech-l about the full sized version of [[bcl:file:Wiki.png]] not being purged. (Of interest, both the commons image and the wikitech-l thread image only seem to be not purged from North America. Europe squids are apparently fine. Which is odd as I would expect the opposite) Also discussion on 'pedia https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=527864677#No_purging_on_newer_version_of_images

Hmm, there's apparently a "live hack" 1.21wmf6 commenting out

/*
if ( $wgUseSquid ) {
        $u = SquidUpdate::newFromTitles( $titleArray );
        $u->doUpdate();
} */

in job/jobs/HTMLCacheUpdateJob.php. I'm not sure why it would be commented out, but that would prevent squids being purged for redirects and pages that have templates being updated afaik.

(In reply to comment #11)

Hmm, there's apparently a "live hack" 1.21wmf6 commenting out

Been there since r96834 (1.17 - sept 12 2011) So i guess not responsible for any new issues. Perhaps nobody ever noticed that all our redirects (and template updates, image updates - I'm assuming LinksUpdate jobs don't send squid purge) are really outdated for anon users. After all anons rarely represent our "technical" userbase.

mathias.schindler wrote:

(In reply to comment #12)

(In reply to comment #11)

Hmm, there's apparently a "live hack" 1.21wmf6 commenting out

Been there since r96834 (1.17 - sept 12 2011) So i guess not responsible for
any new issues. Perhaps nobody ever noticed that all our redirects (and
template updates, image updates - I'm assuming LinksUpdate jobs don't send
squid purge) are really outdated for anon users. After all anons rarely
represent our "technical" userbase.

Given the fact that the report of caching issues came in july 2012 and this bug received little attention since then, the timeline still holds.

This needs retesting now that the infrastructure has changed a lot (move to a new datacenter in January).

Mathias: Is this still a problem?

mathias.schindler wrote:

I never experienced the problem myself, I merely opened a bug report after a friend of mine blogged about the issue (see comment #1)

I am going to ask him.

By the way, the thing I was talking about earlier on got reverted so is no longer an issue - see bug 43341. Im almost certain that was causing the issue your friend was seeing so im going to close this. If your friend still experiances any issues please reopen this bug