On 05/10/2013 14:56, Konstantin Preißer wrote: > Hi Niki, thank you for your reply. > >> -----Original Message----- From: Niki Dokovski >> [mailto:nick...@gmail.com] 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. <snip/> > 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). Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
