Python insecure channel doesn't close properly when Exception is raised

[nathanielmanistaatgoogle]

A user writes:

I've been writing a GRPC client using the Python library, but I'm having some issues with the connection not being closed.  Here's a quick example:

from grpc.beta import implementations

from grpc.framework import interfaces

from dummy_pb2 import *



def main():

    channel = implementations.insecure_channel('localhost', 8000)

    stub = beta_create_Dummy_stub(channel)

    raise Exception()



if __name__ == "__main__":

    main()


This code will hang after raising the Exception.  However, this only seems to happen when an Exception is raised.  If I remove the statement to raise the Exception, the code exits cleanly.  Is there some issue with Python GRPC's cleanup when exceptions occur? 

[kasey]

In my testing this error occurred any time an error was returned from a grpc method. Eg if you modified this line in the hello world example:
https://github.com/grpc/grpc-go/blob/master/examples/helloworld/greeter_server/main.go#L54

to:
return &pb.HelloReply{Message: "Hello " + in.Name}, errors.New("noooooo")
(+ import "errors", of course)

a request from a python client should hang. I'm happy to provide more specifics or contribute a complete example to help debug.

I haven't attempted to use secure_channel to determine if this is specific to insecure_channel.

[kasey]

Here's an example stack trace:

# python -m py_proto.client
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
    exec code in run_globals
  File "/build/py_proto/client.py", line 30, in <module>
    main(host, port)
  File "/build/py_proto/client.py", line 24, in main
    validate_response = call_validate(channel, item)
  File "/build/py_proto/client.py", line 15, in call_validate
    response = stub.Validate(item, _TIMEOUT_SECONDS)
  File "/usr/local/lib/python2.7/dist-packages/grpc/framework/crust/implementations.py", line 75, in __call__
    protocol_options, metadata, request)
  File "/usr/local/lib/python2.7/dist-packages/grpc/framework/crust/_calls.py", line 109, in blocking_unary_unary
    return next(rendezvous)
  File "/usr/local/lib/python2.7/dist-packages/grpc/framework/crust/_control.py", line 415, in next
    raise self._termination.abortion_error
grpc.framework.interfaces.face.face.RemoteError: RemoteError(code=StatusCode.UNKNOWN, details="Insufficient number of characters in item.GridCell: len("") == 0")
^CError in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/usr/local/lib/python2.7/dist-packages/concurrent/futures/thread.py", line 39, in _python_exit
    t.join(sys.maxint)
  File "/usr/lib/python2.7/threading.py", line 960, in join
    self.__block.wait(delay)
  File "/usr/lib/python2.7/threading.py", line 358, in wait
    _sleep(delay)
KeyboardInterrupt

^^^ note that there are two tracebacks in this snip, the second after I ^C'd the program.

[GuoJing]

I think this issue is related with #4969 , if channel and stub not closed (not called exit), everything get stuck.

CTRL+C will not work.

[kpayson64]

Verified that the issue is fixed after the GA changes, the program properly exists on raising an exception both before and after the connection is established.

[kasey]

@kpayson64 by GA presumably you mean the 0.15 release? Now that this issue is closed I'm hoping to track the fix to a release point so I can incorporate it once it's available (either via pypi or a source build). Looks like pypi is updated promptly after the release tag comes down, so I'll watch the github release page https://github.com/grpc/grpc/releases (unless you recommend I watch somewhere else)

[kpayson64]

@kasey Yes, this fix will be incorporated into the 0.15 release.