[
https://issues.apache.org/jira/browse/THRIFT-5371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer updated THRIFT-5371:
-------------------------------
Fix Version/s: 0.25.0
> 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
> Priority: Major
> Fix For: 0.25.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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.20.10#820010)
