[
https://issues.apache.org/jira/browse/THRIFT-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443159#comment-17443159
]
Jens Geyer commented on THRIFT-5480:
------------------------------------
Thanks, will have a look.
The proposed reset effectively puts the maximum allowed value back into place.
This is unfortunate here, because framed enables us to to know the real size
and the patch just decides to forget it, hence all operations that happen
afterwards will check again against the maximum instead of the real size. The
patch fixes the actual symptom by making the checks weaker.
> 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)
