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

Jim Crossley jim at crossleys.org
Tue Sep 16 23:27:22 EDT 2014


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>
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>> wrote:
>>
>>
>>
>>     Sent from my iPhone
>>
>>     >  On Sep 16, 2014, at 8:19 PM, Jim Crossley <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.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20140916/91091c78/attachment.html 


More information about the undertow-dev mailing list