The problem is due to the way Protocols and Transports handle the end of streams.
Basically what happens is that we read a first message correctly, then we try to read another message from the buffer we have no more data
So, in TBinaryProtocol.readMessageBegin, we starts by reading an Int32 from the streambuffer, but as the buffer is empty, it return undefined, then the rest of the function is complete garbage (but it doesn't crash), so the exception is thrown from the processor. The MultiplexedProcessor see the error (by side effect), and throw a thrift.TException which is not catched by the server.
It doesn't happens with:
- TBufferedTransport because ensureAvailable is called before each reads
- TJSONProtocol because we check for the stream length before reading it (borrow + readindex)
- Non Multiplexed Protocol: because MultiplexedPrcessor throw its own error (thrift.TException) which is not catched above, however what happens is that a thrift exception is thrown on the wire after each requests when using regularprocessor/framedtransport/binaryprotocol
I think that the best way to handle it is to check that there is enough data before extracting it from the buffer in the functions TBinaryProtocol.readInt/String/.... and to throw a underbuffer error if necessary