[
https://issues.apache.org/jira/browse/THRIFT-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443120#comment-17443120
]
Ioannis Efthymiou commented on THRIFT-5480:
-------------------------------------------
I added a minimal example server, and a python client. You could try different
versions of clients as well. You can see that you can't call the first method
after you've called the second method. As a matter of fact, the transport will
be closed on the server side, from TEndpointTransport.ResetConsumedMessageSize
throwing a TTransportException.
I was under the impression that the check disabled, it's just reset for the
next time it's needed. I suppose I missed something
> TThreadPoolAsyncServer using TFramedTransport mistakenly drops client
> ---------------------------------------------------------------------
>
> Key: THRIFT-5480
> URL: https://issues.apache.org/jira/browse/THRIFT-5480
> Project: Thrift
> Issue Type: Bug
> Components: netstd - Library
> Affects Versions: 0.15.0
> Reporter: Ioannis Efthymiou
> Assignee: Jens Geyer
> Priority: Major
> Labels: Oneway, TFramedTransport, TThreadPoolAsyncServer
> Attachments:
> 0001-Reset-message-size-in-TFramedTransport.ReadFrameAsyn-1.patch,
> ThriftBug.zip
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> TThreadPoolAsyncServer using TFramedTransport silently drops a client service
> using oneway methods when the second message is bigger than the first one.
> I have an application implementing a one way service, depending on it's
> state. I created a TThreadpoolAsync server using the netstd 0.15 version, and
> I noticed that after a point, the notifications stopped coming, but there was
> no error on either side. The methods all worked individually, but some did
> not work after others.
> Eliminating all possible causes on my side, I debugged the source code, and
> discovered that a transport exception was thrown from TEndpointTransport when
> a message size was bigger than the proceeding one, because
> TFramedTransport.ReadFrameAsync was not resetting the message size when it
> was done reading it, thus causing TEndpointTransport.UpdateKnownMessageSize
> to throw the exception. The server interpreted the exception as if the client
> had disconnected, so it silently ignored it.
>
> I've attached a patch that corrects this behaviour
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
