On 04/30/2013 09:42 PM, Amos Jeffries wrote:
On 1/05/2013 4:04 a.m., Luciano Ruete wrote:
Hi,
We are using squid 3.2.9 (but I checked change log up to 3.2.11
before writing this mail).
If a user behind proxy starts a long file download and in the
meantime we do a -k rotate, that download gets broken.
I think this is a bug.
If it is actually Squid breaking the download that would be a bug.
However -k rotate does not do anything with active connections.
It:
* restarts helpers, gracefully so that all pending requests are still
served. It MAY break connections which are midway through NTLM
handshake setup, but that is a transitory issue and disappears
immediately on client retry.
* renames the log files and starts writing to the new main log(s).
* dumps the cache index journal out to a new file (swap.state) and
starts using the new clean journal from that point onwards.
Apart from the swap.state generation all of this takes a few dozen
milliseconds at most. I'm not sure how long the swap.state writing
takes and how it overaps with the post-rotate resumption.
So can you please check your cache.log and system messages log
carefully to ensure that; a) Squid is not in fact crashing during the
rotate - which would definitely cut all transactions and b) how long
the rotation is taking in the active worker process - more than a few
ms rotation pausing time by Squid would allow TCP and NAT state timers
to run out and play havoc with random connections.
Hi,
I can confirm that squid is not crashing during rotate, and also the
rotation is taking "0.01 seconds (2874035.41 entries/sec)." and similar.
We are recording logs in a tmpfs (RAM mounted as disk) in order to free
disk IO, and this RAM disk is only 1GB in size, so we start to rotate
every 10 minutes with a cron job using -k rotate.
After this users start to complain that they can not download large
files, and with further test we reduce this to exec -k rotate and
instantly cut the user download.
Currently we are using a single worker (workers = 1) and a single
cache_dir.
