You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "Alan Baines (JIRA)" <ji...@apache.org> on 2019/07/29 20:13:00 UTC

[jira] [Created] (THRIFT-4913) Type errors in a Python Thrift Client using Named Pipes with TJSONProtocol or TBinaryProtocol irreversibility break communication layer

Alan Baines created THRIFT-4913:
-----------------------------------

             Summary: Type errors in a Python Thrift Client using Named Pipes 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

File Transport using Named Pipes

TJSONProtocol | TBinaryProtocol
            Reporter: Alan Baines


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)