https://bugzilla.wikimedia.org/show_bug.cgi?id=18571
Summary: Purging images does not always force image metadata
cache to be cleared
Product: MediaWiki
Version: 1.15-svn
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: Images and files
AssignedTo: [email protected]
ReportedBy: [email protected]
Created an attachment (id=6054)
--> (https://bugzilla.wikimedia.org/attachment.cgi?id=6054)
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 ).
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
