On 11/04/2012 6:47 p.m., Jean-Philippe Menil wrote:
Le 05/04/2012 16:50, Jean-Philippe Menil a écrit :
Le 04/04/2012 09:00, Jean-Philippe Menil a écrit :
On 03/04/2012 23:53, Amos Jeffries wrote:
On 04.04.2012 02:46, Jean-Philippe Menil wrote:
Le 03/04/2012 11:06, Jean-Philippe Menil a écrit :
Hi,
i encounter serious outage with squid 3.HEAD-20120307-r12077.
Every time i download some test files, it stop after 15 minutes.
If i go down read_timeout to 1 minutes, the download stop after 1
minutes.
Is it a know issue, or must i increment read_timeout to excessively
timeout?
special configuration is as follow:
workers 4
cpu_affinity_map process_numbers=1,2,3,4 cores=6,7,8,9
Regards.
Nobody have ever observe this phenomen?
Not many production networks (squid-users people) use 3.HEAD
(alpha) code.
The developers and alpha/beta testers hang out in squid-dev ;)
And no, you are the first to mention this particular behaviour.
Amos
Hi,
yes iknow, but i think it is present in 3.2 too (i will test this
afternoon to confirm).
I think i can repeat that only when download a file to on a https
site, does it help?
Regards.
Hi,
so i have done test with a squid 3.2.0.14.
And it appear that i can repeat the problem only with https site, why
i don't know yet.
For test, i fixe a lower value (don't want to wait 15 minutes between
each test) for read_timeout,
and i download an iso file through some https site:
https://nzdis.org/projects/projects/perfnet/repository/revisions/4/raw/vendor/Vyatta/Vyatta/vyatta-livecd-vc5.0.2.iso
Every time, the download stop at the read_timeout value.
Any ideas?
Regards.
Hi,
sorry to up this subject, but i can't understand why the
read_timeout isn't zeroed with https communication.
Do i miss something?
Read timeout should be reset to full on every packet read. It is never
zeroed during a transfer.
It sounds like the transfer is stalling for more than read timeout, or
the timeout is not being reset like it should be.
Amos
