buffer corruption in camel-netty?

[tenderice <te...@gmail.com>]

I got a strange error when using netty(with camel), we use
LengthFieldBasedFrameDecoder for communication, sometimes got two messages
"merged" into one, and hence the forthcoming data get all wrong.

for example:

client send two messages:

[10]AAAAAAAAAAAAAAAA and [10]BBBBBBBBBBBBBBBB

where [10] is the length bytes and AAAAAAAAAA is the data.

but on the server we got [10]AAAAAA[10]BBBBBBBBBBBBBBBBAAAAAAAAAA

seems the the first message got split by the second one, so the decoder
interpreted the data as:

[10]AAAAAA[10]BBBBBBBB

and

BBBBBBBBAAAAAAAAAA...................................................

so that the first message is correct in length but wrong in data, and the
second message is wrong in length "BB", and get a much longer data packet.

hope I described clearly, anyone met this before? I'm not sure whether it is
a netty bug or a camel-netty one, hope someone can help.

--
View this message in context: http://camel.465427.n5.nabble.com/buffer-corruption-in-camel-netty-tp5551122p5551122.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: buffer corruption in camel-netty?

[tenderice <te...@gmail.com>]

anybody helps?

--
View this message in context: http://camel.465427.n5.nabble.com/buffer-corruption-in-camel-netty-tp5551122p5554011.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: buffer corruption in camel-netty?

[tenderice <te...@gmail.com>]

well, this proved to be a "bug" of camel-netty component, I will post a fix
to camel project later on. Before that, please be careful using the
camel-netty component, especially do not use encoders/decoders not mark with
@sharable annotation, it will lead to the problem since state maybe shared
among different connections.

--
View this message in context: http://camel.465427.n5.nabble.com/buffer-corruption-in-camel-netty-tp5551122p5575040.html
Sent from the Camel - Users mailing list archive at Nabble.com.