[undertow-dev] Async sending of NIO objects thru a ServletOutputStream?

Stuart Douglas sdouglas at redhat.com
Tue Sep 16 23:28:53 EDT 2014


That is not really is issue, the issue is that non blocking channels 
require some way of registering a listener, so that you can be notified 
when more data is available. Without some form of listener all you can 
do is read in a busy loop :-(

Stuart

Jim Crossley wrote:
> Interesting. Is the non-blocking alternative to change the "while..." to
> "if (!_eof)"? There's no problem with writing _buffer when
> hasRemaining() is true, is there?
>
> On Tue, Sep 16, 2014 at 11:03 PM, Stuart Douglas <sdouglas at redhat.com
> <mailto:sdouglas at redhat.com>> wrote:
>
>
>     1068            // Read from stream until buffer full or EOF
>     1069            _buffer.clear();
>     1070            while (_buffer.hasRemaining() && !_eof)
>     1071              _eof = (_in.read(_buffer)) <  0;
>
>     That pattern for reading from the stream only works for blocking IO.
>     If you are using a non blocking channel this will basically wait in
>     a busy loop till data becomes available.
>
>     Stuart
>
>     Jim Crossley wrote:
>
>         Thanks, Jason. To me, the Jetty code looks like it's doing
>         pretty much
>         what Stuart told me to do. Can you tell me which part exactly
>         assumes
>         the blocking behavior so I can relay that to the Pedestal guys?
>
>         On Tue, Sep 16, 2014 at 10:33 PM, Jason T. Greene
>         <jgreene at redhat.com <mailto:jgreene at redhat.com>
>         <mailto:jgreene at redhat.com <mailto:jgreene at redhat.com>>> wrote:
>
>
>
>              Sent from my iPhone
>
>         >   On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim at crossleys.org
>         <mailto:jim at crossleys.org>
>         <mailto:jim at crossleys.org <mailto:jim at crossleys.org>>> wrote:
>         >
>         >   Is this an async or a blocking transfer? The problem with
>         >  > ReadableByteChannel is that it can be a blocking channel,
>         and as a
>         >  > result reading from it in the IO thread will result in crappy
>         >  > performance.
>         >
>         >   Because of the way they're using it (with Clojure's core.async
>              library)
>         >   I expect the transfer to be async, but I'll verify that with
>         them.
>
>              I just looked at the Jetty impl, and the code assumes blocking
>              behavior with that method. Anything using it will be
>         blocking reads
>              with non blocking writes.
>
>
>


More information about the undertow-dev mailing list