[
https://issues.apache.org/jira/browse/THRIFT-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15049405#comment-15049405
]
Josh Elser commented on THRIFT-3479:
------------------------------------
Oh, great. Thanks for the link Roger. I hadn't stumbled onto that testing page
on my own yet. That will be very helpful.
I'll take a look at that and get back to ya'll.
> 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)
