Hi Mark and Christopher, For clarification, suppose a client sends and HTTP POST request which is bigger than the PMTU and has to be broken into multiple packets. It sounds like you're saying that the request is buffered by the network stack, and the stack does not send it up to tomcat until the full request is received. That would make sense if every HTTP request is encapsulated in its own separate TCP connection. Most of the time, that is not the case. A single connection is held open and used for multiple HTTP requests. The network stack has no understanding of anything above TCP, so it does not know when an HTTP request complete. It must therefore deliver whatever it has, and it would be up to tomcat to decide when the HTTP request is complete, wouldn't it?
If that is the case, tomcat could receive a partial HTTP request and would have to wait for the rest before processing it. So when does tomcat start its processing timer? > -----Original Message----- > From: Christopher Schultz <ch...@christopherschultz.net> > Sent: Tuesday, September 8, 2020 1:19 PM > To: users@tomcat.apache.org > Subject: Re: Tomcat Processing Timer Question > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Eric, > > On 9/8/20 13:46, Eric Robinson wrote: > > It is my understanding that the AccessLogValve %D field records the > > time from when the last byte of the client's request is received to > > when the last byte of the server's response is placed on the wire. Is > > that correct? If so, would TCP retransmissions impact the timer? > > I'm not positive, but I believe Tomcat has zero visibility into that level of > detail. > > > If there are connectivity issues between the client and server, > > resulting in TCP retransmits, could that appear as higher response > > times in the localhost_access logs? > > This would only happen if the re-transmissions were to cause network > buffering in the OS such that the stream writes (at the Java level) were to > block (and therefore "take time" instead of being essentially instantaneous). > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9XyvUACgkQHPApP > 6U8 > pFi2PQ/9Er4fN490tP2Fq911WSX7+wQnnRwE9w5JWx36b++DtFAWxKJTpQGg > 0Dl2 > pyP/1vVPB6ZHVPdVEUUvYPAzhDAVWJVrIdXUvcaMg2tKpb5zzERhdxpG2vEH > Qykb > YaRTPqu0QHNySjMyQ9yT3Q8YDSObvXAYnR+7f1aT1g9UOma63z4mKE11RuQl > oXGz > SqjiLzHjDQmehplDjTXTSwRxcjnJftCKG0Jwin4f8Kto6tJ/AJdTxaWmwXeSiRcn > QN8b586DpyS/k0hgkJ0bOWhbxVsy4aUhM+PeyjN4AXufzSjymY4hv4hpOO+3 > 7woT > SRj3rTd2LtS8h5v4VVSIFXTeL+kEwjo3iya/Komd4Z7Pu+qw91ZLy7LIrZfV4MHp > 8me2jLobBiosIlXSAAxVjY3zOVlzqEOIjOL+t/Qwhn+CM/nDLfuhtwdfuu+KGpN > s > /u18gauI4eb4MtoSETcvb5OaFHdkrmInCD3BXz9ZZRrnVCL9r9SLPN1yxENerdV > q > RJrvJMItb5tLf0XcK7Wvm+lJIdArEkSCzZ3o3uDWbiRkN0hKU5R/Jndr/qfL12dj > /knGWyED0UGaY58TgOMAN6veMO991/PTL6to5Xr6RTivEQO+6YYS1zj1uGPc5 > p/n > gGnJ9b9VWeZBvlyDb7H9CxOvvkdJzMum6WaagIvmR5zi8ZZx3do= > =QoNs > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Disclaimer : This email and any files transmitted with it are confidential and intended solely for intended recipients. If you are not the named addressee you should not disseminate, distribute, copy or alter this email. Any views or opinions presented in this email are solely those of the author and might not represent those of Physician Select Management. Warning: Although Physician Select Management has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
