You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Paul Caswell (Jira)" <ji...@apache.org> on 2021/03/16 17:10:00 UTC

[jira] [Created] (THRIFT-5371) Max Message Size is eventually exceeded when using TFramedTransport

Paul Caswell created THRIFT-5371:
------------------------------------

             Summary: Max Message Size is eventually exceeded when using TFramedTransport
                 Key: THRIFT-5371
                 URL: https://issues.apache.org/jira/browse/THRIFT-5371
             Project: Thrift
          Issue Type: Bug
          Components: C++ - Library
    Affects Versions: 0.14.1
         Environment: Windows 2010, Visual Studio 2017, CMake 3.15.2
            Reporter: Paul Caswell


I have been trying to upgrade our application from Thrift 0.11.0 to 0.14.1 and have noticed what I think is a bug.

Our thrift application uses a TFramedTransport to transmit large quantities of data from the client to the server using a oneway call.  The transports are all created using the (new) default TConfiguration class giving a maximum message size of 100MB.  

Our application sends data through the thrift library in circa 10MB blocks using a oneway call.  On the 10th call the server terminates with a TTransportException thrown on line 329 of TTransport.h.

I believe this is happening because the TFramedTransport doesn't reset the 'knownMessageSize_' and 'remainingMessageSize_' counters when a message transfer is completed.  This means that the counter continually reduces until the exception is thrown.  I am new to the thrift library and so perhaps I have this wrong but it's what looks like is happening to me.

I can make the library work by adding resetConsumedMessageSize(); inside TFramedTransport::readEnd() in file TBufferTransports.cpp (at line 310).  Is this the correct solution?

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)