On 28/10/2020 20:32, Mark Thomas wrote: <snip/>
> I have the off-list mail and will start looking at the logs shortly. Progress. I think. I'll start with the following summary of the log data. Source Time Activity ==================================================== pcap 15:14:25.375451 SYN proxy to Tomcat pcap 15:14:25.375493 SYN, ACK Tomcat to proxy pcap 15:14:25.375839 ACK proxy to Tomcat pcap 15:14:25.375892 GET request proxy to Tomcat pcap 15:14:25.375911 ACK Tomcat to proxy debug 15:14:25.376 o.a.c.http11.InternalOutputBuffer.init pcap 15:14:25.376777 FIN Tomcat to proxy pcap 15:14:25.377036 FIN, ACK proxy to Tomcat pcap 15:14:25.377048 ACK Tomcat proxy debug 15:14:25.383 o.a.c.http11.InternalOutputBuffer.commit debug 15:14:25.383 o.a.c.http11.InternalOutputBuffer$1.doWrite debug 15:14:25.383 o.a.c.http11.InternalOutputBuffer$1.nextRequest debug 15:14:25.383 o.a.c.http11.InternalOutputBuffer$1.recycle Tomcat writes the request body to the buffer but when Tomcat tries to flush those bytes out to the network it finds that the socket has been closed. That normally indicates that the client has dropped the connection. This is sufficiently common that Tomcat swallows the exception. However, we know (from the pcap file) that the client did not drop the connection, Tomcat did. What is strange here is that with BIO is there is a 1-2-1 relationship between threads and sockets for the life of the socket. While I can see how a retained reference could truncate a response (including the headers) I don't yet see how the socket could get closed. I think more debug logging is required. I am currently working on that. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
