[
https://issues.apache.org/jira/browse/THRIFT-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443090#comment-17443090
]
Jens Geyer edited comment on THRIFT-5480 at 11/13/21, 12:34 PM:
----------------------------------------------------------------
But TFramed works perfectly in other scenarios. Sure you fixed the right place?
Also, by resetting the msgsize at that particular place you essentially disable
the check entirely. Lets throw it out then since we don't need it anyway,
should we? No, we should not, because there is a good reason for these checks.
Would be helpful if you could provide a full test case. Possible?
was (Author: jensg):
But TFramed works perfectly in other scenarios. Sure you fixed the right place?
> Netstd - 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
> Priority: Major
> Labels: Oneway, TFramedTransport, TThreadPoolAsyncServer
> Attachments:
> 0001-Reset-message-size-in-TFramedTransport.ReadFrameAsyn-1.patch
>
>
> 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)
