tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Preißer <kpreis...@apache.org>
Subject RE: 8.0.x / 7.0.x progress
Date Sat, 05 Oct 2013 19:42:16 GMT
Hi Mark,
thanks for your reply.

> -----Original Message-----
> From: Mark Thomas [mailto:markt@apache.org]
> Sent: Saturday, October 5, 2013 9:00 PM
> To: Tomcat Developers List
> Subject: Re: 8.0.x / 7.0.x progress

> 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, will do.

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

OK, that makes sense to me.

One question, would it be possible to make Session.getAsyncRemote() throw some RuntimeException
when using the BIO connector, instead of silently using blocking writes? As the methods are
in fact blocking with BIO (but it is documented that they are async), this may be a surprise
to someone which doesn't know much about the BIO and NIO connectors of Tomcat when he relies
on that methods being run asynchronously but in fact will be blocking, and then uses such
an application in production (where the problems might not show up immediately when doing
some tests).

If getAsyncRemote() instead threw an exception saying that you need NIO or APR for this method,
I think this might save someone such a surprise (but I must admit that I do not know much
about Servlet 3.1's NIO features and how there the situation is with BIO connector).

What do you think?


Regards,
Konstantin Preißer


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message