tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: 8.0.x / 7.0.x progress
Date Sat, 05 Oct 2013 18:59:38 GMT
On 05/10/2013 14:56, Konstantin Prei├čer wrote:
> Hi Niki, thank you for your reply.
>> -----Original Message----- From: Niki Dokovski
>> [] Sent: Saturday, October 5, 2013 7:47 AM 
>> To: Tomcat Developers List Subject: Re: 8.0.x / 7.0.x progress
>>> I have installed Wireshark now and can confirm that Firefox
>>> (after it is resumed) still sends data over the TCP connection
>>> which Tomcat seems not
>> to
>>> be able to read.
>> Are there ACKs for the TCP packets? I'll try to reproduce the
>> case.
> Yes, I verified with Wireshark that Tomcat ACKs these packets
> correctly, but does not seem to be able to process them. I continued
> to send data from Firefox (SEQ went up to 61373) to ensure that the
> ACKs were not just resulting from buffering somewhere in the Windows
> or Java network stack, and I can confirm that Tomcat still ACKed
> these SEQ numbers.
> Note, that when using the BIO connector, everything works fine - the
> problems only appear with NIO or APR connector.

OK. Create a Bugzilla entry for this one. It could be a Tomcat issue, it
could also be lack of error handling in the snake example.

>>> OK, but my understanding was that there is a difference between
>>> the
>> terms
>>> "synchronous/asynchronous" and "blocking/non-blocking" (but maybe
>>> the meaning differs from programming language to programming
>>> language).

There are but...

WebSocket is built on top of Servlet 3.1 non-blocking IO. When you use
the BIO connector the non-blocking IO API still works but it uses
blocking IO.

It might be possible to refactor the BIO aspect so the observed
behaviour is more similar to NIO and APR/native but that will make
scalability worse rather than better as now you'll have two threads per
connection rather than one.


> The problem is now that if Tomcat's implementation of this
> Async#sendText(...) method is blocking when using the BIO connector,
> it will mean that with BIO I get the problem again that the snakes
> will stop moving on all clients if one client stops reading data
> (might be considered as a DoS), but if I use NIO or APR, everything
> will be fine. That would mean that I have to use different
> implementations of broadcasting data to clients, depending on the
> underlying connector that is being used (blocking or non-blocking).

Or, don't use BIO. It is going to get removed at some point, possibly
for Tomcat 9. There is a reason Tomcat 8 uses NIO by default and this is
part of it.

I'm leaning towards documentation being the way to address this - i.e.
make clear that if you use the BIO connector then various NIO components
either won't work (Comet) or will actually block (Servlet 3.1).


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

View raw message