8:24 p.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>>