Large File Transfers with Delimiter/BufferSize Channel Handlers

[Trustin Lee]

Hi,

The second FrameDecoder doesn't need to be implemented with FrameDecoder because the first one defragmented the received data already.  I would simply make the second one extend OneToOneDecoder for higher performance.

--
Trustin Lee - http://gleamynode.net/
Sent from a mobile device - please excuse the brevity.

On Dec 22, 2010, at 1:08 AM, greymeister <greymeister at gmail.com> wrote:

> 
> Hello, I'm looking for some input on how to set up my Channel Pipeline for
> best performance given the requirements I have.  I'm accepting raw file
> transfers from clients that will be delimited by a specific character
> sequence.  I set up the pipeline initially to put a custom
> DelimiterBasedFrameDecoder implementation which simply initializes with the
> correct delimiter.  The next item in the pipeline is a custom FrameDecoder
> which prevents the final handler from getting any content unless the size is
>> length of the delimiter.  This prevents the handler from receiving just
> the delimiter string, instead it gets the entire buffer.  
> 
> The current implementation solves the problem, but it seems as though
> performance goes down much faster than linearly as the files sent get larger
> in size.  I would expect linear decrease in performance based on the buffer
> size, but at a certain point it seems to almost become unresponsive.  Are
> there any options which would allow for my current solution to scale better? 
> Is this sort of Delimiter/Frame Size solution only applicable for small
> frames?
> 
> Thanks!
> -- 
> View this message in context: http://netty-forums-and-mailing-lists.685743.n2.nabble.com/Large-File-Transfers-with-Delimiter-BufferSize-Channel-Handlers-tp5855629p5855629.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users