[
https://issues.apache.org/jira/browse/THRIFT-5480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5480.
--------------------------------
Fix Version/s: 0.16.0
Resolution: Fixed
> 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
> Fix For: 0.16.0
>
> Attachments:
> 0001-Reset-message-size-in-TFramedTransport.ReadFrameAsyn-1.patch,
> ThriftBug.zip
>
> Time Spent: 40m
> 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)
