Page MenuHomePhabricator

SquidPurgeClient hangs on response from Squid Cache 2.7, or multiple entries in $wgSquidServers
Open, LowPublic

Description

Author: jayhuggins

Description:
Squid Cache 2.7 returns a "Connection: close" header which SquidPurgeClient doesn't recognize or recover from appropriately, resulting in a semi-infinite loop in the SquidPurgeClientPool.run() function, loading the CPU until the loop breaks for a timeout. Besides the loading and slowing page edits, this bug also prevents some of the purge requests in the pool from being sent at all.

Also, SquirPurgeClientPool doesn't handle multiple squids (multiple entries in $wgSquidServers) because the indexing scheme for $readSockets and $writeSockets in SquidPurgeClientPool.run() is flattened by the socket_select function, and only the first server in the $wgSquidServers array actually receives the purge request. Again, SquidPurgeClientPool.run() enters a semi-infinite loop as a result, loading the CPU and causing page edits to be very slow in their response.


OS: Linux
Platform: Other

Details

Reference
bz37063

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:29 AM
bzimport set Reference to bz37063.
bzimport added a subscriber: Unknown Object (MLST).

jayhuggins wrote:

Note: we discovered this bug in MediaWiki 1.16 and verified it is still in the 1.20 code.

Lowering priority on high priority bugs that have a low severity

needs more work, won't make it into 1.20.0