Clients crashing a Netty Server using LengthFieldBasedFrameDecoder

[Christian Migowski]

Hi,

unless there is some "mark" in your protocol data to "synchronize" the
decoder with the data stream from the wire again the decoder "state"
is permanently corrupted thus making it defunct, this is correct.

This is why FrameDecoder (parent of LengthFieldBasedFrameDecoder)
should be used one per Channel and not one for all created Channels
(this is also marked with the annotation
@ChannelPipelineCoverage("one") in framedecoder, maybe this annotation
could be included in the LengthFieldBasedFrameDecoder to make this
more visible).

So you need to use bootstrap.setPipelineFactory() instead of getting
the default pipeline via bootstrap.getPipeline();

hth,
regards,
christian!

On Fri, Oct 16, 2009 at 11:57 AM, phi6 <phidinh6 at gmail.com> wrote:
>
> I've come across a problem which is a little bit worrying, so want to ask you
> guys for advice if I've done the right thing or not.
>
> In my pipeline I have a LengthFieldBasedFrameDecoder, which basically looks
> at the first 2 bytes (short int) and then stripping it out to determine the
> length of the rest of the message.
>
> Now, I accidentally sent a message with some bytes representing a UTF8
> string (the content) but forgot to prepend it with the 2 byte header. So it
> seems that the decoder could no longer resolve the length of the message
> (not sure what is happening there) but from this point the server is unable
> to receive messages from that or any other client. I am able to connect
> clients fine, but messages doesn't seem to be propagating through the
> pipeline.
>
> Any ideas? Let me know if this is clear
>