On Tue, 2012-03-06 at 13:56 +0000, Mark Thomas wrote:
> > Well if you block when trying to read then why not just use the blocking
> > API? If
> > there is a good use case then I am open to relaxing that restriction.
>
> I was thinking about this in the context of Tomcat's three connectors -
> one of which uses blocking IO (BIO). There are reasons why a user may
> prefer the BIO connector. Async IO can't work with BIO with the
> restriction in place.
Not adding this would make the upgraded API not scale, since any thread
can then be stuck due to a slow client. This means that the application
has to use one thread per connection on output to be able to avoid DoS
attempts (even involuntary ones).
It should be possible to use tricks to avoid blocking even for java.io
(write in another thread, send the event when it is done), of course
with a large performance cost.
> Lifting the restriction seems to be the simplest solution.
-1
Besides, I have no idea how you would implement the Servlet 3.1 IO,
which has the same async support for output
(WriteListener.onWritePossible should be the same as
ProtocolHandler.outputReady).
Similar to that, I would like the upgraded connections to gave the same
sleep/resume that is provided with Servlet 3.0 async, to make thread
handling container managed, at least for the IO portion.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc