On 12/05/17 12:49, Juan Ramírez wrote:
Hi,
Mi name is Juan, I am a Software Engineer from Uruguay. I think this
message is more suited to the squid-dev mailing list due to the
developer-oriented nature of the message but, given that the
development list is for people who actually contributes code to Squid,
I chose to post here.
Membership is for those people, the list itself acts as a focal point
for anyone such as yourself with this query to contact them without
having to know particular peoples contacts.
As to your issue;
Requests which are not retriable are not able to be re-sent if it turns
out they got even partially delivered on a pre-opened persistent
connection which happened to be in the process of closing by the other
endpoint unknown to Squid. For example if the timing of the write to
deliver the ICAP RESPMOD headers overlapped with the TCP FIN/RST packets
coming from a router along the network path, or the ICAP service itself.
As such those requests need a new TCP connection to be opened to
guarantee the absence of immediate closure. When they complete with
their transaction it gets added to the pool for other traffic to use if
they can.
The behaviour which you describe was designed to prevent the ICAP pool
from absorbing all available TCP resources through these constant brand
new TCP connections being needed then added to the pool. Which would
leave the proxy unable to receive HTTP traffic as there would be no TCP
sockets/ports available for non-ICAP connections.
If your service only (or mostly) has non-retriable transactions occuring
it can be more efficient to disable persistence o speed up the turn
around on TCP socket closures. Persistence is useful for when you have
many retriable transactions occuring which can use pooled connections
and be re-tried if something barfs at the TCP level.
As far as I know RESPMOD transactions should all be retriable unless the
body payload length is unknown at the HTTP level (lack of Content-Length
header).
They can also become non-retriable when the response from the ICAP
server has been received by Squid and already started delivery to the
HTTP client. That is the noteCommRead call - to prevent the connection
being pooled if the connection suddenly closes before it completes. This
should not have any effect on whether a pooled connection was used to
start with, but will affect whether a pooled connection gets used on the
retry attempt to prevent the same issue/delay repeating indefinitely to
the same client.
(PS. Alex knows a lot more about the details of this design than me, so
if he says anything contradicting the above go with his).
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
