tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: 8.0.x / 7.0.x progress
Date Mon, 07 Oct 2013 14:39:39 GMT

On 10/7/13 10:24 AM, Konstantin Prei├čer wrote:
>> -----Original Message-----
>> From: Christopher Schultz []
>> Sent: Monday, October 7, 2013 3:29 PM
>> To: Tomcat Developers List
>> Subject: Re: 8.0.x / 7.0.x progress
>> Konstantin,
>> Note that it's not Tomcat sending the ACKs, but the TCP/IP stack in the
>> OS running underneath the JVM. I wanted to point that out because it
>> means that Tomcat may be entirely unaware that data exists for reading
>> for some reason. If Tomcat itself were sending the ACKs, it would mean
>> that Tomcat was at least conceptually aware of the data, but refusing to
>> read it for some reason.
> Yes, that's correct. I guess there is some buffering in the various
> layers (TCP/IP stack of OS, Sockets in the JVM etc) so that when sending
> data, the client receive ACKS with a new window size even if the remote
> java code might not be reading the data.


> However, the buffering will not be endlessly so at some point TCP 
> will advertise a window of 0 if the java code does not read from the
> Socket (at least this will be the case with blocking IO - though I do
> not exactly know how the non-blocking IO is implemented so I may as
> well be wrong here). This would mean that Firefox will have to wait
> until there is more window available to continue sending data.

I'm not sure how big the average TCP/IP receive buffer size is. I'd
suspect a few MBs at least. It's bufferbloat at its finest ;)

> In this case, I guess to verify that the remote TCP endpoint is 
> actually reading the data, one would have to send much bigger
> messages to make sure the buffer of the remote endpoint runs out of
> space if it is not reading from the connection. I can try that if I
> have some time left.

Just add a few zeros to your loop limit ;)


View raw message