[
https://issues.apache.org/jira/browse/THRIFT-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605179#comment-17605179
]
Philip Lee commented on THRIFT-5628:
------------------------------------
Flush is called for send requests which is why this issue doesn't happen for
sends. Would it make sense to call Flush on reads?
For symmetry with the send code above the read code would need to be
var tmp195 = await
InputProtocol.ReadMessageBeginAsync(cancellationToken);
if (tmp195.Type == TMessageType.Exception)
{
var tmp196 = await TApplicationException.ReadAsync(InputProtocol,
cancellationToken);
await InputProtocol.ReadMessageEndAsync(cancellationToken);
await InputProtocol.<Something>(); // Flush doesn't sound right
throw tmp196;
}
var tmp197 = new InternalStructs.get_next_waveform_result();
await tmp197.ReadAsync(InputProtocol, cancellationToken);
await InputProtocol.ReadMessageEndAsync(cancellationToken);
await InputProtocol.<Something>(); // Flush doesn't sound right
Or make ReadMessageEndAsync do the right thing.
I notice the C++ version has
{code:java}
uint32_t readEnd() override {
// This cast should be safe, because buffer_'s size is a uint32_t
auto bytes = static_cast<uint32_t>(rBase_ - buffer_);
if (rBase_ == wBase_) {
resetBuffer();
}
resetConsumedMessageSize();
return bytes;
}{code}
> MaxMessageSize is never reset on a read buffer
> ----------------------------------------------
>
> Key: THRIFT-5628
> URL: https://issues.apache.org/jira/browse/THRIFT-5628
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Library
> Affects Versions: 0.16.0
> Reporter: Philip Lee
> Priority: Major
>
> It appears that for the ReadBuffer of a TMemoryBufferTransport the method
> CountConsumedMessageBytes() is called, but ResetConsumedMessageSize() is
> never called.
> Our code as a long lived client which is polling periodically for an extended
> time. RemainingMessageSize eventually falls to <= 0 and a
> TTransportException("MaxMessageSize reached") is then thrown.
> Is this a bug or expected?
> I can fix this by changing TMemoryBufferTransport as follows
> {code:java}
> public override ValueTask<int> ReadAsync(byte[] buffer, int offset, int
> length, CancellationToken cancellationToken)
> {
> var count = Math.Min(Length - Position, length);
> Buffer.BlockCopy(Bytes, Position, buffer, offset, count);
> Position += count;
> CountConsumedMessageBytes(count);
> ---> ResetConsumedMessageSize();
> return new ValueTask<int>(count);
> }{code}
> but not confident this is correct.
> Or as a work around I can set TConfiguration.MaxMessageSize = int.MaxValue
> which will allow our code to operate for longer (20x) before failing.
> Or I can recreate the client periodically.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
