In our application we have a client/server pair that initiate their connection with a small handshake protocol P1, after which they switch to another protocol P2.
For P1 protocol the pipeline is initialised with the following handlers:
LengthFieldBasedFrameDecoder
P1ProtocolMessageDecoder
LengthFieldPrepender
P1ProtocolMessageEncoder
After the P1 handshake protocol is successfully completed, the traffic should switch to the P2 Protocol, in which case we first clear the pipeline and then add a separate set of handlers
P2MessageDecoder
P2MessageEncoder
IdleHandler
Switching the pipeline is done when last expected message in P1 protocol is received:
// switch traffic to P2 protocol
clearPipeline();
addNewHandlers();
The problem encountered is that LengthFieldBasedFrameDecoder removal triggers an unexpected read (because the are bytes left unread in the handler's ByteBuf). But, since at that point in time, the pipeline is empty (was cleared, but new handlers not yet added), the inbound message gets dropped.
Is there any "safe" way to do the pipeline switch without triggering an unwanted read during the time the handlers are not in place yet?
Thanks
Later Edit:
I've read about replacing decoders here: (The part titled "Replacing a decoder with another decoder in a pipeline")
http://netty.io/4.0/api/io/netty/handler/codec/ReplayingDecoder.html
The workaround I've applied successfully was to:
removeOldNonByteToMessageHandlers();
addNewHandlers()
removeOldByteToMessageHandlers();
// when the "leftover bytes" read is triggered the new handlers are already in place
My solution seems hacky. Is there a better "netty-er" way of achieving this?