Channel.isWritable()

[jasons2645]

Thanks!  I'll give it a try.  In the meantime, I figured out a solution to
the problem I was having:
When ingress data comes in faster than it can be processed, call
setReadable( false ) on the channel, changing it back to true later once
processing has completed.


Trustin Lee wrote:
> 
> 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/
> 
> 
>  
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
> 
> 

-- 
View this message in context: http://n2.nabble.com/Channel.isWritable%28%29-tp3068932p3087930.html
Sent from the Netty User Group mailing list archive at Nabble.com.