[ https://issues.apache.org/jira/browse/THRIFT-5628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17605168#comment-17605168 ]
Jens Geyer commented on THRIFT-5628: ------------------------------------ {quote}I'm thinking that ReadMessageEndAsync should reset MaxMessageSize.{quote} Makes sense. But not ReadAsync as you proposed above. > 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)