On 20/04/2012 8:27 p.m., Jean-Philippe Menil wrote:
Hi,
like disussed earlier on the squid-users mailing list
(http://www.squid-cache.org/mail-archive/squid-users/201204/0280.html);
i experiment problem due to read_timeout not reset correctly in
tunnel.cc.
Example:
when i download a file on https site, the download stop on the
read_timeout value.
It can be esealy repeat:
read_timeout 30 seconds
(the defautl is 15 minutes, but it fail too)
wget --no-check-certificate
https://nzdis.org/projects/projects/perfnet/repository/revisions/4/raw/vendor/Vyatta/Vyatta/vyatta-livecd-vc5.0.2.iso
-O /dev/null
With the following (obvious) patch, i can't repeat the problem:
01-build64:/home/menil-jp/squid-3.2.0.17# diff src/tunnel.cc
/tmp/squid-3.2.0.17/src/tunnel.cc
321,326d320
< if (Comm::IsConnOpen(to.conn)) {
< AsyncCall::Pointer timeoutCall = commCbCall(5, 4, "tunnelTimeout",
< CommTimeoutCbPtrFun(tunnelTimeout, this));
< commSetConnTimeout(to.conn, Config.Timeout.read, timeoutCall);
< }
<
333,336c327,330
< /* Only close the remote end if we've finished queueing data to it */
< if (from.len == 0 && Comm::IsConnOpen(to.conn) ) {
< to.conn->close();
< }
Please, can anyone confirm this problem?
Sorry, finally found some spare time.
If I'm reading that function right this timeout is occuring on CONNECT
where the traffic flow is all one-way for the duration of the timeout right?
ie, tunnel gets setup. Request bytes sent down it from client->server,
then server sends response data for >N seconds with not one more byte
from client->server. N being the timeout value.
Which would make the timeout correct. Read has not occured on the client
connection for N seconds. But not suitable for two-way CONNECT tunnel.
The proper solution would probably be to bump read timeout when data is
successfully written to the connection
(writeClientDone/writeServerDone). So we did not keep bumping read
timout on a aborted connection.
Any other opinions?
Amos
