tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <>
Subject RE: 8.0.x / 7.0.x progress
Date Mon, 07 Oct 2013 14:24:22 GMT
Hi Christopher,

thank you for your reply.

> -----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.

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.


Konstantin Preißer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message