Last modified: 2009-04-24 23:11:19 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 T20571, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 18571 - Purging images does not always force image metadata cache to be cleared
Purging images does not always force image metadata cache to be cleared
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
1.15.x
All Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-24 07:42 UTC by nephele
Modified: 2009-04-24 23:11 UTC (History)
1 user (show)

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


Attachments
Purge cache even if cache says file doesn't exist (640 bytes, patch)
2009-04-24 07:42 UTC, nephele
Details

Description nephele 2009-04-24 07:42:57 UTC
Created attachment 6054 [details]
Purge cache even if cache says file doesn't exist

Inevitably, there are occasionally problems that happen when an image is uploaded.  Wiki editors have come to expect that if something unexpected happens, one of the first steps to try is purging the image (e.g., enter a URL such as http://www.uesp.net/w/index.php?title=Image:TR3-npc-Brelyn_Dreloth.jpg&action=purge) -- and that the purge should force the generated image summary page to be refreshed.  However, purging an image does not always force a refresh.

Specifically, some problems can result in memcached metadata for an image that incorrectly states that an image does not exist -- even though metadata for the image exists in the database, and even though the file exists in the local w/images directory and thumbnails exist in the w/images/thumb directory.  Once this happens, a purge request on the image is basically ineffective -- there is no way for wiki editors to force the server to clean out its bad memcache information.  The problem in the code is that ImagePage::doPurge() first checks to see whether the image exists, and skips all of the purging if the image does not exist -- or rather if it ''thinks'' that the image does not exist.  It never explicitly makes sure that the cached information is correct.  A purge request should always force the code to verify in one way or another that the cached information is up to date.

The attached patch is a simple fix for the problem -- ensuring that PurgeCache is always called.

For those wondering how this situation can occur in the first place, it can happen following image upload problems if a wiki is running multiple content servers.  If a problem (upload connection timing out, etc) results in a failure to write the image metadata to the database, multiple content servers can subsequently end up caching the image's nonexistence in their individual memcaches of the metadata.  When the file is re-uploaded, only the single server that processes the new image upload registers that the file now exists; all of the other content servers are stuck permanently accessing their incorrect cached metadata.  Different servers end up returning different results; there is no way for editors to fix the problem; and, diagnoses based on the assumption that purge has regenerated a page are completely misguided (this long discussion is an example of the confusion and false conclusions that result when purge isn't doing what it should: http://www.uesp.net/wiki/User_talk:Daveh#Urgent:_Possible_Disk_Space_Problem ).
Comment 1 Chad H. 2009-04-24 23:11:19 UTC
Done in r49848

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


Navigation
Links