Channel.isWritable()

["이희승 (Trustin Lee)"]

Hello Jason,

I was busy implementing an interesting feature, which will be
interesting especially to you.  :)

I've just added a handler implementation that allows you to send a list
of chunks without getting OutOfMemoryError and without any hiccup.  If
you are interested in how it was implemented, please take a look at the
source code:


http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/handler/stream/ChunkedWriteHandler.java?r=1377

I also wrote a simplistic web server example that is dedicated to
serving static files:


http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/file

To explain briefly:

  * ChunkedWriteHandler was added in the pipeline after the encoder so
that ChunkedInput is picked up and read chunk by chunk.

  * A ChunkedFile (implements ChunkedInput) instance was written out to
the channel so that ChunkedWriteHandler writes its content chunk by chunk.

Please let me know if ChunkedWriteHandler doesn't work for you.  I'd be
glad to help you.

HTH,
Trustin

On 2009-06-13 오전 2:30, jasons2645 wrote:
> 
> First off, let me provide a little background on what I am doing.  I have a
> server that sends potentially large files (up to 4GB) to clients.  Both the
> server and client are using Netty.  Since RAM is limited on both boxes, the
> server reads the large file 4K at a time, sending these 4K chunks to the
> client, which writes them to disk.
> 
> 
> 
> Since the server can read these 4K chunks from the disk much faster than it
> can send them over the network, it must have some mechanism to know when the
> Netty write buffer for the channel has become 'too full', and then wait for
> it to come down in size before attempting to send more data.  Otherwise,
> this write buffer will grow too quickly and blow the top off the JVM on the
> server.
> 
> 
> 
> To accomplish the above, I tried 2 approaches (neither worked):
> 
> 1) Whenever the server goes to write a 4K chunk to the channel, it waits
> until the channel reports true for isWritable.
> 
> 2) I reflectively got a hold of the channel's current write buffer size
> (yes, this is hacky), and whenever the server went to write a 4K chunk to
> the channel, it waited until the write buffer size dropped below 64K.
> 
> 
> 
> In both of these cases, the server would send data for a while and then
> stop.  After further investigation, I discovered that the server had written
> more data to the wire than the client had read off the wire.  It was as if
> the client needed more chunks before it would notify its ChannelHandler that
> a message had arrived.  Sure enough, when I modified approach (1) above so
> that the server waited for up to 300ms, then sent the data anyway, the code
> worked (although rather slowly, since there are occasional 300ms hiccups).
> 
> 
> 
> Is the behavior I've seen a bug?  Or is there something I'm doing wrong /
> another mechanism I should be using to accomplish this?  Thanks in advance!


-- 
— Trustin Lee, http://gleamynode.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20090616/19882e8b/attachment.bin