The main reason is that camel-netty's DefaultServerPipelineFactory stores decoders/encoders in NettyConfiguration object and use them when a new pipeline is created. This mechanism of creating and using referenced parameter works fine for most camel components, however will cause problem when the netty decoder/encoder is not sharable, that is, the object has state. For example, LengthFieldBasedFrameDecoder and any class that derive from FrameDecoder are all not sharable, one must create a new object each time a pipeline is established, rather than share an instance among all connections.
Although you can write your own PipeLineFactory to avoid the problem (by creating the decoder/encoder each time), however that makes the mechanism of referenced decoders/encoders quite useless, and still there is no way to prevent people from making such mistake.
I currently use a solution by storing the encoder/decoder name in the Configuration object rather than the object instance, and create a new object each time by looking it up from SpringContext, with the help of "prototype" tag in the bean configuration. However, this method is only compatible with Spring ApplicationContextRegistry.
So I think the underlying question is that "is there a best practice for creating referenced object each time when it is used", or, say, "does the configuration model of camel has this kind of ability?" I didn't dig into all components to find the solution, please who can point out a component or give a suggestion for solving this problem, I can make the modification.
Re: camel-netty bug and the need of best practice for creating referenced parameter object on looking-up
below is a very simple testcase for this problem, due to the random nature of the bug, you can get different result each time you run the program. However, if you create a new decoder in the pipelinefactory each time, you get the correct result.
The idea of the test is: create two endpoint, listening on two port, send data to these ports, first send port of data to port1, the send some thing to port two, then send rest data to port1. we expect that port1 receive all data correctly.