[
https://issues.apache.org/jira/browse/THRIFT-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15202844#comment-15202844
]
Hudson commented on THRIFT-3479:
--------------------------------
SUCCESS: Integrated in Thrift-precommit #335 (See
[https://builds.apache.org/job/Thrift-precommit/335/])
THRIFT-3479 Avoid returning a message to a client on TException. (nsuke:
[https://github.com/apache/thrift/commit/b3a42dd050db2657a589b7b73e3d121211649fe5])
* lib/java/src/org/apache/thrift/ProcessFunction.java
> 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)
