https://bugzilla.wikimedia.org/show_bug.cgi?id=41130
Aaron Schulz <aschulz4...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |m...@nedworks.org
--- Comment #9 from Aaron Schulz <aschulz4...@gmail.com> 2012-10-24 01:24:39
UTC ---
This isn't really easy to prevent. One can do a few things:
a) Change SquidPurgeClientPool to return some status info on run() that checks
if any of the sockets where marked as "down" (got a non 200/404 message). Then
change the squid purge code to be first, and to not purge anything in swift
unless the squid purge succeeded. This would still be vulnerable to race
conditions (you can purge afterwards again but have the same issue as before).
b) Make the same SquidPurgeClientPool change as (a) and have a list of
thumbnails logged somewhere if anything failed to purge. This list could be
reused by ?action=purge or job runners automatically re-trying in the
background or something.
c) Hack squid to support prefix PURGE requests somehow.
d) Have fixed thumbnails sizes so there are a reasonable number of a priori
urls to purge, so ?action=purge can fix failed purges.
One could also change the squid settings to revalidate more using HEADs to
swift (which would trigger 404 handling and a fresh thumbnail in this broken
case where they don't exist). This would increase latency and traffic, and
still wouldn't deal with the immediate confusion upon some re-uploads.
Another work around to some extent is to reduce the network problems (amount of
dropped packets? htcp purge rely script?) or purge requests failures so this at
least occurs less often. It might be useful to have Mark look at this.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
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
