[squid-dev] Issue detected in squid 2.7 version
Amos Jeffries
squid3 at treenet.co.nz
Fri Oct 31 05:40:38 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 31/10/2014 6:20 p.m., scanty babu wrote:
> Hi,
>
> We are using squid 2.7.7 version in our production environment and
> recently faced an issue with this version.
Hi Scanty,
Squid Project support for 2.7 was dropped several years ago. Are you
able to upgrade to a currently supported version?
>
> The scenario: 1. Slow Client side connection 2. Fast Server side
> connection 3. Client sends a range request from the end eg. 10000
> byte Content length and the client requests 0-9500 bytes.
>
> Client connection being slow, the server side reads get
> automatically stopped when the data to be written to the client is
> more than the ReadAhead gap(16KB, default in our case).
>
> The server side reads are resumed when all the data in memory has
> been written to the client. The mechanism of defer and resume keeps
> occurring during the length of the download.
>
> This mechanism works properly in most of the cases, except where
> Range request are involved. The client gets the requested range of
> bytes, but does not flip DEFER_READ flag on the server side FD. So,
> server reads wait for about 15 minutes(timeout) and connection is
> closed. The HTTP object is released from the store even though the
> server has sent the complete object.
>
>
> The solution: fwdDeferReadCheck function checks if the server side
> reads have to be resumed/deferred. As DEFER_READ flag is still set
> on the FD reads will never resume.So, we put a check
>
>
> - if (EBIT_TEST(e->flags, ENTRY_DEFER_READ)) { +
> Server-side fd stuck in defer state after client has received the
> byte range requested by it. + Unblocking the server side
> connection, if there is no pending client waiting on a store entry
> object. + If the pending data is more than quick_abort_max,
> then the connection will be aborted by squid + */ + if
> (EBIT_TEST(e->flags, ENTRY_DEFER_READ) && +
> storePendingNClients(e)!=0 ) { commDeferFD(mem->serverfd); return
> 1; }
>
> If there is more data to be read from the server, the
> quick_abort_max configuration will make sure squid aborts the
> connection
>
> Just wanted to bring to notice this issue in 2.7 version, so that
> it can be fixed in latest squid versions 3.x (if present).
>
> Also, please advise if we are doing it correctly (or if it could
> be done otherwise).
Bug reports should be submitted through our bugzilla. But they will
only be accepted if they can be demonstrated to occur in the latest
supported version.
Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQEcBAEBAgAGBQJUUyDWAAoJELJo5wb/XPRj5RUIAJPJtw0LUjt6a1sGFzsq4GUv
7oZg6rwWUf81sa76a87Y6MsDDKo4JRZhwGTChlcV8xYNfxLB+oMoqgQoFjORj7fU
e/v2+pVRhlkW8giXG0eBrE6Srp3CGXE69BvBSip9ArtMsDrOmYEvFwiucGWYAo4r
uVt4bBmnYCS30OQ/ZustliZa2+RdW6jKwDJiuMTJs3Kk9o+xkOAzXjICuQVqFj7B
rximbl6J0XZ0QnhmATO3b8wB0JgS0zdCAUylVV2DCs/ARTg3YffaSgy8gIvDa3qq
ZXxA2zaKN2V6sxXlKcJ4HaeIdvQfR2xbR6QKN/+AU5gkWdk1JdA5FfNjs+hwZbE=
=4m3Z
-----END PGP SIGNATURE-----
More information about the squid-dev
mailing list