https://bugzilla.wikimedia.org/show_bug.cgi?id=28613
--- Comment #21 from Brion Vibber <br...@wikimedia.org> 2011-06-30 22:18:59 UTC --- Quick summary of issue: How it's supposed to work: * during re-upload (between successful file save and 'image' table data update), all previously-rendered thumbnails are removed from disk and then purged from HTTP caches (LocalFile::purgeThumbnails) * subsequent requests for previously-existing thumbnails should now cause a cache miss on the HTTP caches, falling through to the upload server -- there is no thumbnail file so it falls through to the image scaler backend which produces a new file, outputs it over HTTP and saves it to disk * subsequent requests for those thumbnails should return the new file, either via the HTTP caches or directly if it falls out of cache again The visible problem: * sometimes after re-uploading, old thumbnails are still seen even when forcing a reload (indicating old file is at least in HTTP cache), but new image can be forced by changing query string (indicating that the new file can get created) Some possibilities of 'tricky things' off the top of my head: * the purges might be getting sent incorrectly (I don't see URL-escaping being applied on the filename portion of purged thumbnail URLs -- however most of the cases listed above show filenames that would not be affected by this.) * some thumbnails might not be on disk, in which case they would not be purged at all on reupload (would require something else that removes thumbnail files but fails to send a successful purge, or else inability to save the original file when it was generated?) ^ these above two can be tested by logging the purge requests and comparing them to see if affected files were in fact purged. * the purges might be getting sent correctly, but not taking effect somehow (?) * the purges might be getting sent and taking effect, but something causes the old file to be re-loaded and re-cached immediately (could this happen if some cache servers have processed the clear and others haven't yet, and another request comes in and gets passed from a server that just cleared it to a server that hasn't cleared it yet, thus restoring the old file to cache?) ^ I'm not sure offhand how the internals work on the actual purge implementation or how the cache servers handle peer requests, so this could be either a legit issue or totally unbreakable. -- 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 Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
