[
https://issues.apache.org/jira/browse/THRIFT-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Sukegawa resolved THRIFT-3479.
----------------------------------
Resolution: Fixed
Assignee: Josh Elser
> Oneway calls should not return exceptions to clients
> ----------------------------------------------------
>
> Key: THRIFT-3479
> URL: https://issues.apache.org/jira/browse/THRIFT-3479
> Project: Thrift
> Issue Type: Bug
> Components: Java - Library
> Affects Versions: 0.9.1, 0.9.2, 0.9.3
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Critical
> Fix For: 0.10.0
>
> Attachments: THRIFT-3479.001.patch
>
>
> We noticed the following happening over in ACCUMULO-4065.
> A client made a oneway call to a server which ultimately caused a TException
> to propagate up through to ProcessFunction. This caused a message to be sent
> back to the client with a TApplicationException wrapping the TException.
> The problem is that the client had already returned its connection to a pool
> because it was oneway (it had no means to know when the call finished -- nor
> did it care). The next client that tried to send an RPC to the same server
> sent its message, then read the response off the wire, only to get the oneway
> call's exception Message, not the response for the call it made.
> Ultimately, this screwed up the connection (the next client was always
> reading the previous clients response).
> Given my understanding on the current implementation (mostly discerned from
> the docs, a bit from code), it's my belief that oneway calls can never safely
> return a message to clients.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
