On Fri, 13 Feb 1998, Apiset Tananchai wrote:
>
> I already apply that patch to my squid server but the problem still occur
> (approximately once a minute). If I remember correctly, Michael Pelletier
> used to told me that the connection-retry patch has nothing to do after
> the connection to www server established so it would not solve my problem.
> I want something that will retry connection that get "Connection reset by
> peer" error a few times befor give up.
Yes, that's correct -- the retry patch will only retry
connection-establishment problems, such as when a server is down or busy,
and it works best when the site has several IP addresses, such as
Microsoft.
Apiset's error occurs after the connection is established, which a few
layers out from the retrying that the retry patch does within the
commConnectHandle() routine, which is within commConnectStart(), within
httpConnect(), which is a *handler* within ipcache_nbgethostbyname()
within the httpStart(), ftpStart(), gopherStart(), etc. routines called
from a switch in protoStart().
You begin to see the reason I implemented the retry in commConnectHandle()
-- that was the place to do it while making the absolute least change in
the code. Retrying connections that are already established, but have
closed unexpectedly, is, from what I can tell, a bit more complex due to
the handler-based pseudo-multi-threaded architecture of Squid. I'll dig
into it a bit more and see what I can come up with, perhaps I'm just not
conversant enough with the nuances of the use of Squid's handlers to see
an obvious solution.
And I suppose another question is whether automatically retrying
established-but-dropped connections is a good idea in general. At first
glance that would seem to tangle with a few other areas, such as dealing
with the partially-retrieved cache object correctly.
-Mike Pelletier.
Received on Fri Feb 13 1998 - 06:02:58 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:38:52 MST