Re: HTTP client disconnection vs ICAP disconnection

From: Tsantilas Christos <chtsanti_at_users.sourceforge.net>
Date: Tue, 01 Feb 2011 20:59:28 +0200

Hi John,
   I did some simple tests and I am not seeing this problem on trunk or
on the latest squid-3.1 on bzr repository. The connection to the icap
server always closed.
Is it possible to be an icap server bug?

The debug section for the squid ICAP client is the 93. Try to enable
debug to see if you can understand where the problem is:
   debug_options ALL,1 93,9

On 02/01/2011 07:58 PM, John Craws wrote:
> Hi,
>
> Thanks for your reply. However, I should have added that:
>
> 1. I do not see FDs reused if the request is aborted. I see them
> reused if the request completes.
> 2. This is the case even with 'icap_persistent_connections off'.
>
> Thanks,
>
> John Craws
>
> ----------------
>
> On 01/02/11 09:04, John Craws wrote:
>
> Hello,
>
> I am going through the source code of 3.1.9/3.1.10 trying to find the
> cause of a problem I am seeing with a squid instance configured to use
> an ICAP service.
>
> The setup works fine, but if the client (wget) is disconnected while
> the response is being transferred (CTRL-C while receiving relatively
> large data), the ICAP socket is never disconnected. This leads to a
> situation where the ICAP service is perpetually timing out on a read
> operation on that socket.
>
> I have not seen this occur with other ICAP services.
>
> I would definitely appreciate if someone with better knowledge of this
> part of the code could help me pinpoint where the relationship between
> those two is implemented.
>
> As I understand it ICAP should not be aware of the client and has an
> independent set of persistent connections.
>
> The client disconnecting should set the ICAP output handlers to
> discard the rest of the transaction and push the FD into an IdleFdList
> waiting for another client request to use it.
>
> Alex or Christos know more about the finer details.
>
> Amos
> --
> Please be using
> Current Stable Squid 2.7.STABLE9 or 3.1.10
> Beta testers wanted for 3.2.0.4
>
Received on Tue Feb 01 2011 - 18:59:22 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 09 2011 - 12:00:04 MST