[jira] [Comment Edited] (THRIFT-4913) Type errors in a Python Thrift Client with TJSONProtocol or TBinaryProtocol irreversibility break communication layer

["Alan Baines (JIRA)" <ji...@apache.org>]

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

Alan Baines edited comment on THRIFT-4913 at 8/7/19 1:38 PM:
-------------------------------------------------------------

h1. Update

After further investigation, this issue appear to reproduce with *socket* transport (in addition to named pipes), with both JSON and Binary Protocols (and suspect others/all). 
h1. Reproduction Steps

Starting with Python tutorial from [https://thrift.apache.org/tutorial/py] using *sockets*.

Update the client call to *add()* to a type of *string*.
{code:java}
sum_ = client.add("1", 1)
{code}
Depending on the protocol, either the client call will fail or hang, and the client will be unusable for future calls.

 

The major difference between named pipes and socket transport is that when using named pipes often the server's named pipe will be broken too, however using sockets the server never appears to hang/crash/break/fail. 
h1. Summary

In any combination of *socket* or *named pipe* transport with *JSON* or *Binary* protocols, *Type Errors* to the Python client cause the client to irreversibility be unusable for future calls. Failure modes may vary slightly, but the results are the same.


was (Author: abaines):
h1. Update

After further investigation, this issue appear to reproduce with socket transport (in addition to named pipes), with both JSON and Binary Protocols (and suspect others/all). 
h1. Reproduction Steps

Starting with Python tutorial from [https://thrift.apache.org/tutorial/py] using *sockets*.

Update the client call to *add()* to a type of *string*.
{code:java}
sum_ = client.add("1", 1)
{code}
Depending on the protocol, either the client call will fail or hang, and the client will be unusable for future calls.

 

The major difference between named pipes and socket transport is that when using named pipes often the server's named pipe will be broken too, however using sockets the server never appears to hang/crash/break/fail. 
h1. Summary

In any combination of *socket* or *named pipe* transport with *JSON* or *Binary* protocols, *Type Errors* to the Python client cause the client to irreversibility be unusable for future calls. Failure modes may vary slightly, but the results are the same.

> 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)