Steven Licking created THRIFT-5492:
--------------------------------------
Summary: Bogus END_OF_FILE exception
Key: THRIFT-5492
URL: https://issues.apache.org/jira/browse/THRIFT-5492
Project: Thrift
Issue Type: Bug
Components: C++ - Library
Affects Versions: 0.14.1
Reporter: Steven Licking
When using a TMultiplexedProcessor server with TBufferedTransportFactory and
TBinaryProtocolFactory a connection to a client will be closed due to an
END_OF_FILE exception after sending many messages.
It appears that when the client connects, in class TTransport, the
remainingMessageSize_ is set to getMaxMessageSize() which, by default, is
DEFAULT_MAX_MESSAGE_SIZE and is defined to be 100*1024*1024 in TConfiguration.h.
The remainingMessageSize_ is decremented as messages are parsed, for example
when parsing a field in the message that is of type binary I see the code
calling readStringBody in TBinaryProtocol.tcc:455 which then calls
this->trans_->consume(size) which goes to TBufferTransports.h:124 and calls
countConsumedMessageBytes which finally decrements remainingMessageSize_.
However, nothing ever resets remainingMessageSize_, so after it is decremented
from 100*1024*1024 down to zero it fails with an END_OF_FILE exception.
It seems that the remainingMessageSize_ should be reset either when a new
message is received from the client or after a message is processed. However
I'm not quite sure what the intended purpose of remainingMessageSize_ is.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
