Re: [undertow-dev] Async sending of NIO objects thru a ServletOutputStream?
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(a)redhat.com
<mailto: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(a)redhat.com <mailto:jgreene@redhat.com>
<mailto:jgreene@redhat.com <mailto:jgreene@redhat.com>>> wrote:
Sent from my iPhone
> On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim(a)crossleys.org
<mailto:jim@crossleys.org>
<mailto: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.