[jira] Commented: (THRIFT-616) Transport should be reset on error

["David Reiss (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772558#action_12772558 ] 

David Reiss commented on THRIFT-616:
------------------------------------

What is the transport type and error type?

> Transport should be reset on error
> ----------------------------------
>
>                 Key: THRIFT-616
>                 URL: https://issues.apache.org/jira/browse/THRIFT-616
>             Project: Thrift
>          Issue Type: Bug
>          Components: Compiler (Python), Library (Python)
>            Reporter: Julian Scheid
>
> I'm running a recent snapshot and observed the following problem when sending a message from Python: when an error is thrown after _oprot.writeMessageBegin and before _oprot.trans.flush, the data that has already been written remains in the transport's buffer. This seems to cause a deadlock in my case.
> The generated code currently looks like this:
> {code}
> self._oprot.writeMessageBegin(...)
> # snip
> args.write(self._oprot)
> self._oprot.writeMessageEnd()
> self._oprot.trans.flush()
> {code}
> Shouldn't it look like this?:
> {code}
> try:
>    self._oprot.writeMessageBegin(...)
>    # snip
>    self._oprot.writeMessageEnd()
>    self._oprot.trans.flush()
> except:
>    self._oprot.trans.reset()
>    raise
> {code}
> Where trans.reset() would clear the output buffer, for example in TBufferedTransport do "self.__wbuf = StringIO()".
> Am I missing something?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.