1:20 a.m.
Hi guys,
I'm looking to promote Undertow as a preferred alternative to Jetty for the
Pedestal [1] framework.
One Jetty feature it relies on is the async sending of ByteBuffers and
ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two
methods, in particular: sendContent(ByteBuffer, Callback) and
sendContent(ReadableByteChannel, Callback).
I was hoping someone might point me in the right direction of replicating
this behavior with Undertow's ServletOutputStreamImpl. It does have a
write(ByteBuffer) method, but it appears to be blocking. And I was hoping
there might be some XNIO abstraction for dealing with the
ReadableByteChannel, perhaps some example code somewhere?
Any and all help/advice is appreciated!
Jim
[1]: https://github.com/pedestal/pedestal
[2]:
http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-s...
7 a.m.
Jim Crossley wrote:
Hi guys,
I'm looking to promote Undertow as a preferred alternative to Jetty for
the Pedestal [1] framework.
One Jetty feature it relies on is the async sending of ByteBuffers and
ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two
methods, in particular: sendContent(ByteBuffer, Callback) and
sendContent(ReadableByteChannel, Callback).
If you have enabled async mode on the ServletOutputStream then
write(ByteBuffer) will write using async IO, and invoke the write
listener when done. Basically it will work the same as standard servlet
async IO, but with byte buffers.
Stuart
I was hoping someone might point me in the right direction of
replicating this behavior with Undertow's ServletOutputStreamImpl. It
does have a write(ByteBuffer) method, but it appears to be blocking. And
I was hoping there might be some XNIO abstraction for dealing with the
ReadableByteChannel, perhaps some example code somewhere?
Any and all help/advice is appreciated!
Jim
[1]: https://github.com/pedestal/pedestal
[2]:
http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-s...
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev
9:18 a.m.
I actually figured that out, Stuart, thanks. So I have writing a ByteBuffer
covered. Any thoughts on handling the ReadableByteChannel? Looking at the
Jetty impl, it appears I need to read it into one or more ByteBuffers and
then write them out. Should I use the Pooled<ByteBuffer> from the exhange's
connection?
Jim
On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
Jim Crossley wrote:
> Hi guys,
>
> I'm looking to promote Undertow as a preferred alternative to Jetty for
> the Pedestal [1] framework.
>
> One Jetty feature it relies on is the async sending of ByteBuffers and
> ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two
> methods, in particular: sendContent(ByteBuffer, Callback) and
> sendContent(ReadableByteChannel, Callback).
>
If you have enabled async mode on the ServletOutputStream then
write(ByteBuffer) will write using async IO, and invoke the write listener
when done. Basically it will work the same as standard servlet async IO,
but with byte buffers.
Stuart
> I was hoping someone might point me in the right direction of
> replicating this behavior with Undertow's ServletOutputStreamImpl. It
> does have a write(ByteBuffer) method, but it appears to be blocking. And
> I was hoping there might be some XNIO abstraction for dealing with the
> ReadableByteChannel, perhaps some example code somewhere?
>
> Any and all help/advice is appreciated!
> Jim
>
> [1]: https://github.com/pedestal/pedestal
> [2]:
> http://grepcode.com/file/repo1.maven.org/maven2/org.
> eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/
> jetty/server/HttpOutput.java
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
9:37 a.m.
Jim Crossley wrote:
I actually figured that out, Stuart, thanks. So I have writing a
ByteBuffer covered. Any thoughts on handling the ReadableByteChannel?
Looking at the Jetty impl, it appears I need to read it into one or more
ByteBuffers and then write them out. Should I use the Pooled<ByteBuffer>
from the exhange's connection?
Yea, we don't have an easy way to just do that transfer at this stage,
you will need to read into the pooled buffer then write it out.
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.
Stuart
Jim
On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas <sdouglas(a)redhat.com
<mailto:sdouglas@redhat.com>> wrote:
Jim Crossley wrote:
Hi guys,
I'm looking to promote Undertow as a preferred alternative to
Jetty for
the Pedestal [1] framework.
One Jetty feature it relies on is the async sending of
ByteBuffers and
ReadableByteChannels in Jetty's impl of ServletOutputStream [2]. Two
methods, in particular: sendContent(ByteBuffer, Callback) and
sendContent(__ReadableByteChannel, Callback).
If you have enabled async mode on the ServletOutputStream then
write(ByteBuffer) will write using async IO, and invoke the write
listener when done. Basically it will work the same as standard
servlet async IO, but with byte buffers.
Stuart
I was hoping someone might point me in the right direction of
replicating this behavior with Undertow's
ServletOutputStreamImpl. It
does have a write(ByteBuffer) method, but it appears to be
blocking. And
I was hoping there might be some XNIO abstraction for dealing
with the
ReadableByteChannel, perhaps some example code somewhere?
Any and all help/advice is appreciated!
Jim
[1]: https://github.com/pedestal/__pedestal
<https://github.com/pedestal/pedestal>
[2]:
http://grepcode.com/file/__repo1.maven.org/maven2/org.__eclipse.jetty/jet...
<http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-s...
_________________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org>
https://lists.jboss.org/__mailman/listinfo/undertow-dev
<https://lists.jboss.org/mailman/listinfo/undertow-dev>
10:18 a.m.
Stuart Douglas <sdouglas(a)redhat.com> writes:
[...]
Yea, we don't have an easy way to just do that transfer at this
stage,
you will need to read into the pooled buffer then write it out.
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.
You wouldn't happen to have an example of reading one into and out of a
pooled buffer you could point me to, would you? :)
Jim
On Tue, Sep 16, 2014 at 8:37 PM, Stuart Douglas <sdouglas(a)redhat.com> wrote:
Jim Crossley wrote:
> I actually figured that out, Stuart, thanks. So I have writing a
> ByteBuffer covered. Any thoughts on handling the ReadableByteChannel?
> Looking at the Jetty impl, it appears I need to read it into one or more
> ByteBuffers and then write them out. Should I use the Pooled<ByteBuffer>
> from the exhange's connection?
>
Yea, we don't have an easy way to just do that transfer at this stage, you
will need to read into the pooled buffer then write it out.
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.
Stuart
> Jim
>
> On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas <sdouglas(a)redhat.com
> <mailto:sdouglas@redhat.com>> wrote:
>
>
>
> Jim Crossley wrote:
>
> Hi guys,
>
> I'm looking to promote Undertow as a preferred alternative to
> Jetty for
> the Pedestal [1] framework.
>
> One Jetty feature it relies on is the async sending of
> ByteBuffers and
> ReadableByteChannels in Jetty's impl of ServletOutputStream [2].
> Two
> methods, in particular: sendContent(ByteBuffer, Callback) and
> sendContent(__ReadableByteChannel, Callback).
>
>
> If you have enabled async mode on the ServletOutputStream then
> write(ByteBuffer) will write using async IO, and invoke the write
> listener when done. Basically it will work the same as standard
> servlet async IO, but with byte buffers.
>
> Stuart
>
>
> I was hoping someone might point me in the right direction of
> replicating this behavior with Undertow's
> ServletOutputStreamImpl. It
> does have a write(ByteBuffer) method, but it appears to be
> blocking. And
> I was hoping there might be some XNIO abstraction for dealing
> with the
> ReadableByteChannel, perhaps some example code somewhere?
>
> Any and all help/advice is appreciated!
> Jim
>
> [1]: https://github.com/pedestal/__pedestal
> <https://github.com/pedestal/pedestal>
> [2]:
> http://grepcode.com/file/__repo1.maven.org/maven2/org.__
> eclipse.jetty/jetty-server/9.__2.0.v20140526/org/eclipse/__
> jetty/server/HttpOutput.java
> <http://grepcode.com/file/repo1.maven.org/maven2/org.
> eclipse.jetty/jetty-server/9.2.0.v20140526/org/eclipse/
> jetty/server/HttpOutput.java>
>
> _________________________________________________
> undertow-dev mailing list
> undertow-dev(a)lists.jboss.org <mailto:undertow-dev@lists.jboss.org
> >
> https://lists.jboss.org/__mailman/listinfo/undertow-dev
> <https://lists.jboss.org/mailman/listinfo/undertow-dev>
>
>
>
10:24 a.m.
Generally we use org.xnio.ChannelListeners#initiateTransfer, however
that is when we are just transfering between two channels, without any
ServletOutputStream in use.
Basically you just read from the channel, if read returns >0 then call
buffer.flip() and write it to the channel. When the callback is invoked
clear the buffer, and repeat until read returns -1.
I don't know what you do if read returns 0, generally you will just use
whatever async capability the channel has to register some kind of
listener, but that is not provided by the ReadableByteChannel contract.
You do have to make sure that that buffer is freed when you are done
with it though, as buffer leaks are bad news.
Stuart
Jim Crossley wrote:
Stuart Douglas <sdouglas(a)redhat.com
<mailto:sdouglas@redhat.com>> writes:
[...]
> Yea, we don't have an easy way to just do that transfer at this stage,
> you will need to read into the pooled buffer then write it out.
>
> 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.
You wouldn't happen to have an example of reading one into and out of a
pooled buffer you could point me to, would you? :)
Jim
On Tue, Sep 16, 2014 at 8:37 PM, Stuart Douglas <sdouglas(a)redhat.com
<mailto:sdouglas@redhat.com>> wrote:
Jim Crossley wrote:
I actually figured that out, Stuart, thanks. So I have writing a
ByteBuffer covered. Any thoughts on handling the
ReadableByteChannel?
Looking at the Jetty impl, it appears I need to read it into one
or more
ByteBuffers and then write them out. Should I use the
Pooled<ByteBuffer>
from the exhange's connection?
Yea, we don't have an easy way to just do that transfer at this
stage, you will need to read into the pooled buffer then write it out.
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.
Stuart
Jim
On Tue, Sep 16, 2014 at 6:00 PM, Stuart Douglas
<sdouglas(a)redhat.com <mailto:sdouglas@redhat.com>
<mailto:sdouglas@redhat.com <mailto:sdouglas@redhat.com>>> wrote:
Jim Crossley wrote:
Hi guys,
I'm looking to promote Undertow as a preferred
alternative to
Jetty for
the Pedestal [1] framework.
One Jetty feature it relies on is the async sending of
ByteBuffers and
ReadableByteChannels in Jetty's impl of
ServletOutputStream [2]. Two
methods, in particular: sendContent(ByteBuffer,
Callback) and
sendContent(____ReadableByteChannel, Callback).
If you have enabled async mode on the ServletOutputStream then
write(ByteBuffer) will write using async IO, and invoke the
write
listener when done. Basically it will work the same as standard
servlet async IO, but with byte buffers.
Stuart
I was hoping someone might point me in the right
direction of
replicating this behavior with Undertow's
ServletOutputStreamImpl. It
does have a write(ByteBuffer) method, but it appears to be
blocking. And
I was hoping there might be some XNIO abstraction for
dealing
with the
ReadableByteChannel, perhaps some example code somewhere?
Any and all help/advice is appreciated!
Jim
[1]: https://github.com/pedestal/____pedestal
<https://github.com/pedestal/__pedestal>
<https://github.com/pedestal/__pedestal
<https://github.com/pedestal/pedestal>>
[2]:
http://grepcode.com/file/____repo1.maven.org/maven2/org.____eclipse.jetty...
<http://grepcode.com/file/__repo1.maven.org/maven2/org.__eclipse.jetty/jet...
<http://grepcode.com/file/__repo1.maven.org/maven2/org.__eclipse.jetty/jet...
<http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.jetty/jetty-s...
___________________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
<mailto:undertow-dev@lists.jboss.org>
<mailto:undertow-dev@lists.__jboss.org
<mailto:undertow-dev@lists.jboss.org>>
https://lists.jboss.org/____mailman/listinfo/undertow-dev
<https://lists.jboss.org/__mailman/listinfo/undertow-dev>
<https://lists.jboss.org/__mailman/listinfo/undertow-dev
<https://lists.jboss.org/mailman/listinfo/undertow-dev>>
11:33 a.m.
New subject: Async sending of NIO objects thru a ServletOutputStream?
Sent from my iPhone
On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim(a)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.
noon
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>
wrote:
Sent from my iPhone
> On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim(a)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.
12:03 p.m.
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>> wrote:
Sent from my iPhone
> On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim(a)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.
12:27 p.m.
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>
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>> wrote:
>
>
>
> Sent from my iPhone
>
> > On Sep 16, 2014, at 8:19 PM, Jim Crossley <jim(a)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.
>
>
>
12:28 p.m.
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.
3521
days inactive
3522
days old
10 comments
3 participants
participants (3)
-
Jason T. Greene -
Jim Crossley -
Stuart Douglas