On 29/01/19 8:50 am, Matthias Weigel wrote: > Hi Alex, > > this problem just got a lot weirder: > - Upload works fine with debug_options ALL,7 ALL,8 or ALL,9. > - Upload fails with debug_options ALL,6 and lower. > > I created a debug_options ALL,6 cache.log. > http://94.16.117.186/squid/cache.log.3b.gz > > During this test, the following happened at the client: > > Stall at 20:10:38 > Recover at 20:12:47 > Stall at 20:14:11 > Failure at 20:16:17 > > Any ideas? > The FD 18 client->Squid I/O stops happening at 20:10:35.923 with input buffer full and more data apparently waiting to arrive. But the FD 20 Squid->server I/O halted earlier at 20:10:35.437 with a 4KB packet being sent and still waiting for the signal to proceed sending more. At 20:12:47.068 a signal is received finally, but it indicates the server connection has gone away with no reason given. Squid generates a 502 error response and delivers that to the client. The client opens a new connection, does all its TLS handshakes again and re-sends the same very large POST request. Which encounters the same sequence of server stops responding, client buffer fills and "stall" until the server FD is closed. Then again the 502 from Squid but the client does not resume this time. So whatever is going on it looks to me like it is the origin server being a problem. Though you may need to look at the actual TCP packet flow to confirm. I expect you will find that a packet from Squid to the server does not get ACK'd, or a network timeout occurs (NAT or TCP lifetimes are common), ... Or maybe the server is itself dealing with a similar backlog from unresponsive internal agent/component leaving its input buffer to overflow just like Squids one from the client does. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
