[squid-dev] [PATCH] url_rewrite_timeout directive
Alex Rousskov
rousskov at measurement-factory.com
Tue Nov 18 22:51:38 UTC 2014
On 11/16/2014 04:05 AM, Amos Jeffries wrote:
> For the record I am still extremely skeptical about the use-case
> behind this feature.
This is a real use case (or we would not be proposing this feature):
admins want to control what happens when their helper transactions
timeout.
Some of us may prefer to ignore timeouts completely (because they are
usually benign), some may prefer to kill Squid on the first timeout
(so that somebody notices and investigates sooner rather than later),
and some may want to do something in-between. Since both extremes and
especially the range of actions between them are valid in many
environments, our personal preferences are not really that important
here: We should give the admins the knobs they need to do their job
the way they see fit.
> Timeout i a clear sign that the helper or system behind it is
> broken (capacity overload / network congestion). Continuing to use
> such systems in a way which further increases network load is very
> often a bad choice. Hiding the issue an even worse choice.
The above logic is very true in some deployment environments and
completely bogus in others. Fortunately, there is no need to force
everybody use this logic or spend hours discussing the best approach
to dealing with proxy errors. We can just let admins the power to
decide what works best for them!
> My vote on this is -0. Too many problems and still no clear
> use-case has been described[1] for this to be a reasonable
> addition.
> [1] "helper is slow" and "helper times out" are not use-case
> descriptions. They are symptoms of an underlying problem.
They are both a use case and a symptom. I know it is difficult to
imagine, but sometimes admins have to work around symptoms of the
problems they cannot control or cannot fix.
The ability to deal with imperfect helpers has been requested many
times. Squid inability to function when optional helpers misbehave is
a serious flaw that drives users away. As far as the overall
functionality of the proposed feature is concerned, I am sure it would
be welcomed by many, so I am happy to give it +1 if that is needed to
offset your "they should just make perfect helpers instead" -0.
Cheers,
Alex.
More information about the squid-dev
mailing list