[
https://issues.apache.org/jira/browse/THRIFT-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049379#comment-15049379
]
Roger Meier commented on THRIFT-3479:
-------------------------------------
Thanks for the patch!
Yes, one way should behave like this, but we still have the risk that it
behaves different within the languages and we have over 20 of them...
One of the most challenging parts of Thrift is same behavior across languages,
that's why we invested a lot into cross language testing which is described
over here: http://thrift.apache.org/test/
> 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
> Priority: Critical
> Fix For: 0.9.4
>
> 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)
