Squid4 ICAP connection handling

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Squid4 ICAP connection handling

Peter Viskup
Running Squid 4.0.23 the ICAP connections getting "frozen".

proxy:~ $ netstat -ntpa| grep 40620
tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
ESTABLISHED 1165/(squid-1)
tcp        0 2744857 127.0.0.1:1344          127.0.0.1:40620
ESTABLISHED 1211/esets_icap

# after ICAP service restart
proxy:~ $ netstat -ntpa| grep 40620
tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
ESTABLISHED 1165/(squid-1)
tcp        0 2744858 127.0.0.1:1344          127.0.0.1:40620
FIN_WAIT1   -

# later on - squid still keep the connection open
proxy:~ $ netstat -ntpa| grep 40620
tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
ESTABLISHED 1165/(squid-1)

How the ICAP connections are handled?
Was there any change in the code? We didn't experienced this with
Squid3.5 before.

Peter
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid4 ICAP connection handling

Alex Rousskov
On 04/09/2018 06:03 AM, Peter Viskup wrote:

> Running Squid 4.0.23 the ICAP connections getting "frozen".
>
> proxy:~ $ netstat -ntpa| grep 40620
> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
> ESTABLISHED 1165/(squid-1)
> tcp        0 2744857 127.0.0.1:1344          127.0.0.1:40620
> ESTABLISHED 1211/esets_icap
>
> # after ICAP service restart
> proxy:~ $ netstat -ntpa| grep 40620
> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
> ESTABLISHED 1165/(squid-1)
> tcp        0 2744858 127.0.0.1:1344          127.0.0.1:40620
> FIN_WAIT1   -
>
> # later on - squid still keep the connection open
> proxy:~ $ netstat -ntpa| grep 40620
> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
> ESTABLISHED 1165/(squid-1)

> How the ICAP connections are handled?

The question is too general to give a brief useful answer.


> Was there any change in the code?

Yes, a lot of code has changed between Squid v3 and v4, including some
ICAP-related changes.


> We didn't experienced this with Squid3.5 before.

Is there an HTTP transaction associated with (e.g., waiting for) that
stuck ICAP connection?

Can you reproduce this problem with a single HTTP transaction? Or does
it take many transactions to get Squid into this state? If you can
easily reproduce, I recommend filing a bug report with an ALL,9 trace of
the problematic transaction attached.

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Squid4 ICAP connection handling

Peter Viskup
On Mon, Apr 9, 2018 at 4:43 PM, Alex Rousskov <[hidden email]> wrote:

> On 04/09/2018 06:03 AM, Peter Viskup wrote:
>> Running Squid 4.0.23 the ICAP connections getting "frozen".
>>
>> proxy:~ $ netstat -ntpa| grep 40620
>> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
>> ESTABLISHED 1165/(squid-1)
>> tcp        0 2744857 127.0.0.1:1344          127.0.0.1:40620
>> ESTABLISHED 1211/esets_icap
>>
>> # after ICAP service restart
>> proxy:~ $ netstat -ntpa| grep 40620
>> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
>> ESTABLISHED 1165/(squid-1)
>> tcp        0 2744858 127.0.0.1:1344          127.0.0.1:40620
>> FIN_WAIT1   -
>>
>> # later on - squid still keep the connection open
>> proxy:~ $ netstat -ntpa| grep 40620
>> tcp   920144      0 127.0.0.1:40620         127.0.0.1:1344
>> ESTABLISHED 1165/(squid-1)
>
>> How the ICAP connections are handled?
>
> Is there an HTTP transaction associated with (e.g., waiting for) that
> stuck ICAP connection?

Not found the HTTP transaction associated with.

> Can you reproduce this problem with a single HTTP transaction? Or does
> it take many transactions to get Squid into this state? If you can
> easily reproduce, I recommend filing a bug report with an ALL,9 trace of
> the problematic transaction attached.

I can easily reproduce. Will search for the HTTP transaction, but not sure whether I would be able to trace it.

More information in:
https://bugs.squid-cache.org/show_bug.cgi?id=4844

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users