You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Julian Scheid (JIRA)" <ji...@apache.org> on 2009/11/02 12:38:59 UTC
[jira] Created: (THRIFT-616) Transport should be reset on error
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.
[jira] Commented: (THRIFT-616) Transport should be reset on error
Posted by "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.
[jira] Commented: (THRIFT-616) Transport should be reset on error
Posted by "Julian Scheid (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772644#action_12772644 ]
Julian Scheid commented on THRIFT-616:
--------------------------------------
The error was a UnicodeEncodeError (due to THRIFT-395) and the transport a TSocket.
The UnicodeEncodeError is fixed now and shouldn't happen anymore but I still have the impression this is more brittle than it needs to be.
> 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.
[jira] Commented: (THRIFT-616) Transport should be reset on error
Posted by "Julian Scheid (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772652#action_12772652 ]
Julian Scheid commented on THRIFT-616:
--------------------------------------
Here you go.
{code}
Traceback (most recent call last):
File "/redacted/build/python/all/redacted/thrift/protocol/RedactedService.py", line 8979, in Foo
self.send_Foo(arg1, arg2, arg3)
File "/redacted/build/python/all/redacted/thrift/protocol/RedactedService.py", line 8988, in send_Foo
args.write(self._oprot)
File "/redacted/build/python/all/redacted/thrift/protocol/RedactedService.py", line 49636, in write
oprot.writeString(self.arg1)
File "/redacted/misc/thrift-py/thrift/protocol/TBinaryProtocol.py", line 123, in writeString
self.trans.write(str)
File "/redacted/misc/thrift-py/thrift/transport/TTransport.py", line 159, in write
self.__wbuf.write(buf)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 19: ordinal not in range(128)
{code}
> 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.
[jira] Commented: (THRIFT-616) Transport should be reset on error
Posted by "Julian Scheid (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772688#action_12772688 ]
Julian Scheid commented on THRIFT-616:
--------------------------------------
Correction: the transport is a TSocket wrapped in a TBufferedTransport. Here's my code for initializing the client:
{code}
transport = TSocket.TSocket(host, port)
transport = TTransport.TBufferedTransport(transport)
protocol = TBinaryProtocol.TBinaryProtocol(transport)
client = RedactedService.Client(protocol)
transport.open()
{code}
> 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.
[jira] Commented: (THRIFT-616) Transport should be reset on error
Posted by "David Reiss (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/THRIFT-616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12772646#action_12772646 ]
David Reiss commented on THRIFT-616:
------------------------------------
Can you paste a backtrace (at least the part that is within Thrift)?
> 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.