On 11/2/21 12:28 PM, David Touzeau wrote:
> Ok, we will investigate on the Parent Proxy but it seems that when squid
> child claim about TCP failed, it understand that the peer is dead
Yes, that is the side effect of the deficiency I was talking about --
Squid inability to recognize that specific
Ok, we will investigate on the Parent Proxy but it seems that when squid
child claim about TCP failed, it understand that the peer is dead and
the whole surf is stopped during several times ( a squid -k reconfigure
fix the issue quickly ) because it did not have any other path to
forward the
On 11/2/21 10:40 AM, David Touzeau wrote:
> 2021/11/01 16:50:48.787 kid1| 93,3|
> Http::Tunneler::handleReadyRead(conn9812727 local=127.0.0.1:23408
> remote=127.0.0.1:2320 FIRSTUP_PARENT)
> 2021/11/01 16:50:48.787 kid1| 74,5| parse: status-line: proto HTTP/1.1
> 2021/11/01 16:50:48.787 kid1|
Hi,
Take time to enable the debug log an parsing the 10GB of logs
Here the piece of code:
2021/11/01 16:50:48.786 kid1| 33,5| AsyncCall.cc(30) AsyncCall: The
AsyncCall Server::clientWriteDone constructed, this=0x55849cb132b0
[call252226641]
2021/11/01 16:50:48.786 kid1| 5,5| Write.cc(37)
On 11/1/21 7:55 AM, David Touzeau wrote:
> The Squid uses the loopback as a parent.
>
> The same problem occurs:
> 06:19:47 kid1| TCP connection to 127.0.0.1/2320 failed
> 06:15:13 kid1| TCP connection to 127.0.0.1/2320 failed
> 06:14:41 kid1| TCP connection to 127.0.0.1/2320 failed
> 06:14:38
Hello Community,
We use child Squid proxies that connect to boxes that act as parents.
In version 4.x this configuration does not pose any problem.
In version 5.2, since, we have a lot of errors like :
01h 47mn kid1| TCP connection to 10.32.0.18/3150 failed
01h 47mn kid1| TCP connection to
