[
https://issues.apache.org/jira/browse/THRIFT-4913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Baines updated THRIFT-4913:
--------------------------------
Environment:
Windows 10
Thrift 0.12.0
Python 3 Thrift Client
Java Thrift Server
Socket Transport
File Transport using Named Pipes
TJSONProtocol | TBinaryProtocol
was:
Windows 10
Thrift 0.12.0
Python 3 Thrift Client
Java Thrift Server
File Transport using Named Pipes
TJSONProtocol | TBinaryProtocol
Summary: Type errors in a Python Thrift Client with TJSONProtocol or
TBinaryProtocol irreversibility break communication layer (was: Type errors in
a Python Thrift Client using Named Pipes with TJSONProtocol or TBinaryProtocol
irreversibility break communication layer)
> Type errors in a Python Thrift Client with TJSONProtocol or TBinaryProtocol
> irreversibility break communication layer
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-4913
> URL: https://issues.apache.org/jira/browse/THRIFT-4913
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler, Java - Library, Python - Compiler,
> Python - Library
> Affects Versions: 0.12.0
> Environment: Windows 10
> Thrift 0.12.0
> Python 3 Thrift Client
> Java Thrift Server
> Socket Transport
> File Transport using Named Pipes
> TJSONProtocol | TBinaryProtocol
> Reporter: Alan Baines
> Priority: Major
> Attachments: TypeErrorKillsCommunicationLayer.zip
>
>
> h1. Reproduction Steps
> Starting with Python tutorial from [https://thrift.apache.org/tutorial/py]
> Switch the transport layer from sockets to Named Pipes using:
> {code:java}
> pipename = os.path.join(r'\\.\pipe', 'Name_of_pipe')
> pipe = open(pipename, 'rb+', buffering=0)
> itransport = TTransport.TFileObjectTransport(pipe)
> otransport = TTransport.TFileObjectTransport(pipe)
> # similar (but different) issues if FLAG is true or false
> if FLAG:
> iprotocol = TJSONProtocol.TJSONProtocol(itransport)
> oprotocol = TJSONProtocol.TJSONProtocol(otransport)
> else:
> iprotocol = TBinaryProtocol.TBinaryProtocol(itransport)
> oprotocol = TBinaryProtocol.TBinaryProtocol(otransport)
> client = Calculator.Client(iprotocol, oprotocol){code}
> Then use many body of py tutorial to verify Name Pipes work in sunny day
> cases, then (before closing the transport):
> {code:java}
> # Next block works
> try:
> sum_ = client.add(3, 7) # notice the arguments are correct type
> print(sum_ )
> except Exception as e:
> msg = traceback.format_exc()
> print( msg )
> # Next block appears to put communication layer in (partially) broken state
> try:
> sum_ = client.add("3", 7) # notice that the "3" is the wrong type
> print(sum_ )
> except Exception as e:
> msg = traceback.format_exc()
> print( msg )
> # Even though we caught the error, the communication layer appears broken
> # So the next block (that worked before) will now hang/never return
> try:
> sum_ = client.add(3, 7) # notice the arguments are correct type
> print(sum_ )
> except Exception as e:
> msg = traceback.format_exc()
> print( msg ){code}
> The exceptions generated are one of the following:
> {code:java}
> TypeError("'<' not supported between instances of 'str' and 'int'")
> {code}
> Or:
> {code:java}
> error('required argument is not an integer')
> {code}
> Depending if you are using JSON or Binary protocol.
> After both cases, the communication layer is unusable even if the exception
> is caught.
>
> h1. Description
> Is it possible to recover the communication layer after a Type Error?
> Or have Thrift verify|check the types before it tries to put the call into
> the communication layer?
> I would like to avoid [restarting the client-server
> relationship|https://grokbase.com/t/thrift/user/143j939skk/thrift-python-client-fails-to-recover-if-arguments-passed-arent-of-expected-type]
> if possible.
>
> I assume the issue is on the Python Client side, however I've also noticed
> that when using the JSON protocol that some type errors can actually break
> the named pipe on the Java Server side.
>
> I've also noticed that negative numbers (i64) can cause problems, but suspect
> that issue is actually unrelated (and only happens with Binary protocol), but
> mentioning it just in case.
>
> Any help or advice would be greatly appreciated! Thanks!
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
