HttpResponseDecoder buffering data
"이희승 (Trustin Lee)"
trustin at gmail.com
Mon Jul 12 03:54:12 EDT 2010
Hi,
Since HttpMessageDecoder (and its subtypes) does not have any idea when
more content will be received, it blindly splits it into the fixed
length chunks, as you already noticed.
Currently, there's no extension point in HttpMessageDecoder that allows
you to decode the partial data immediately, but I'd like to add one to
meet your (and others') needs. To do so, I'd like to know what exactly
you are doing in your FrameDecoder. Do you transform HttpChunk into
something else, or do you simply replace the content of the HttpChunk?
Please feel free to let me know what you do with your FrameDecoder.
Thanks,
Trustin
On 07/09/2010 06:23 AM, halfempty wrote:
>
> Hi, I'm writing a client for a web server that I do not control. The web
> server allows "subscribing" to a URL, eg, make a GET request to a URL. The
> connection stays open, no content-length is sent down, and data is
> transmitted to the client in a frame format. As the client I would like to
> decode the frames immediately, as they are received over the wire. The time
> between frames could be minutes or longer.
>
> Currently I've implemented a pipeline which contains a HttpResponseDecoder,
> followed by my own FrameDecoder (an extension to
> SimpleChannelUpstreamHandler).
>
> Everything works well except that it appears that my FrameDecoder's
> messageReceived() function is called only when the buffer of the
> HttpResponseDecoder above it is full. In other words, the FrameDecoder does
> not get a chance to decode frames until enough have been transmitted to fill
> the HttpResponseDecoder buffer.
>
> As such, the only way I can force my FrameDecoder to be called immediately
> when data is available is to set the maxChunkSize of the HttpResponseDecoder
> to 1 byte. This succeeds in allowing me to decode data as soon as it
> arrives, but is clearly not efficient.
>
> I can't figure out another way to get the HttpResponseDecoder to immediately
> pass data further down the pipeline. Is there anything I'm missing?
>
> Thanks!
--
what we call human nature in actuality is human habit
http://gleamynode.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 293 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100712/bca6a81c/attachment.bin
More information about the netty-users
mailing list