Last modified: 2013-05-29 07:15:56 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T40879, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 38879 - reports of caching issues
reports of caching issues
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: High normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
aklapper-moreinfo
: testme
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-31 08:03 UTC by Mathias Schindler
Modified: 2013-05-29 07:15 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Mathias Schindler 2012-07-31 08:03:20 UTC
http://notes.computernotizen.de/2012/07/31/hat-die-wikipedia-ein-caching-problem/ is reporting about caching issues. Pages of outdated versions are shown.
Comment 1 Sam Reed (reedy) 2012-07-31 08:29:03 UTC
Logged out?
Comment 2 wikizilla 2012-07-31 08:53:14 UTC
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.
Comment 3 Derk-Jan Hartman 2012-07-31 13:35:32 UTC
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
Comment 4 Bawolff (Brian Wolff) 2012-07-31 19:05:41 UTC
> 
> 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]
Comment 5 wikizilla 2012-07-31 20:08:11 UTC
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
Comment 6 Bawolff (Brian Wolff) 2012-08-02 13:26:37 UTC
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.
Comment 7 Andre Klapper 2012-11-17 15:18:34 UTC
Mathias / wikizilla: Could you please provide the exact URL of an affected page? (Including the % encodings as used).
Comment 8 Mathias Schindler 2012-11-17 15:37:26 UTC
No. Torsten Kleinz maybe.
Comment 9 Bawolff (Brian Wolff) 2012-11-17 20:23:22 UTC
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 ]
Comment 10 Bawolff (Brian Wolff) 2012-12-13 17:16:48 UTC
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
Comment 11 Bawolff (Brian Wolff) 2012-12-14 01:47:09 UTC
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.
Comment 12 Bawolff (Brian Wolff) 2012-12-14 22:26:49 UTC
(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.
Comment 13 Mathias Schindler 2012-12-15 12:21:05 UTC
(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.
Comment 14 Andre Klapper 2013-03-08 09:59:46 UTC
This needs retesting now that the infrastructure has changed a lot (move to a new datacenter in January).

Mathias: Is this still a problem?
Comment 15 Mathias Schindler 2013-03-08 10:06:18 UTC
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.
Comment 16 Bawolff (Brian Wolff) 2013-03-08 14:57:17 UTC
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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links