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@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@redhat.com
<mailto:jgreene@redhat.com>> wrote:



    Sent from my iPhone

    >  On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim@crossleys.org
    <mailto:jim@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.