grpc: Python client get stuck if stub is not created inside a function

Hello again 😃

I don’t know if is a bug or a feature but there is an unexpected behavior: If the stub is created in the __main__ namespace, the process will be stuck in atexit() routines when quitting.

Example with greeter_server.py running:

This client is ok, returns immediately:

$ cat greeter_client_ok.py
from grpc.beta import implementations
import helloworld_pb2

def run():
  channel = implementations.insecure_channel('localhost', 50051)
  stub = helloworld_pb2.beta_create_Greeter_stub(channel)
if __name__ == '__main__':
  run()

This one will never exit:

$ cat greeter_client_ko.py
from grpc.beta import implementations
import helloworld_pb2

channel = implementations.insecure_channel('localhost', 50051)
stub = helloworld_pb2.beta_create_Greeter_stub(channel)

When running it, now, it is stuck, so pressing ^C gives the following backtrace:

$ python greeter_client_ko.py
^C
Error 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 "/home/foo/.local/lib/python2.7/site-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 359, in wait
    _sleep(delay)
KeyboardInterrupt
Error in sys.exitfunc:
Traceback (most recent call last):
  File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
    func(*targs, **kargs)
  File "/home/foo/.local/lib/python2.7/site-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 359, in wait
    _sleep(delay)
KeyboardInterrupt

PS: I am running Debian Jessie on amd64, and grpc from the git master branch

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 18 (8 by maintainers)

Most upvoted comments

@nathanielmanistaatgoogle The primary issue here should already be resolved. #6873 solves the general problem of stub shutdown in the event of an outstanding call, which doesn’t seem to be the case here.

hi

No offend, this is a very serious bug and not one cares about this for a long time.

I doubt if anyone in gRPC Python team is really using Python implement. Yeah, I know, maybe Google have SRE and all the servers always running and will NEVER down for a second. but we don’t, may users don’t.

I don’t care if there is a bug deep in code (maybe), I just care why I can’t stop my application, not only CTRL+C you know, If I have a wsgi application who include my code (of course I want everyone in our team include a client lib and cares nothing), will be blocked, and have to KILL the process.

This is no that hard if you guys cares, right? No one like this.

And because another bug:

https://github.com/grpc/grpc/issues/6730#issuecomment-223198543 https://github.com/grpc/grpc/issues/6730#issuecomment-223198543

I downgrade grpcio from 0.14.x to 0.13.1.

Please

Please care two thing before release:

  1. I could quit my program normally
  2. Reconnect server automatically should work - if it don’t work, please do not block me (iomgr wait for stop), I can’t quit anything, I have to kill -9

I think gRPC is a very good project and I do think is fast, high performance base on HTTP2.

Please let me run a Hello Word easily first.

Thanks and Best wishes

Sorry for poor English.

GuoJing

http://guojing.me http://guojing.me/ The one who love coding. –> ret <– echo null rm -rf /

在 2016年6月2日,上午10:56,zj8487 notifications@github.com 写道:

really hope the issue can be fixed in the GA plan.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/grpc/grpc/issues/4969#issuecomment-223182881, or mute the thread https://github.com/notifications/unsubscribe/AAWKQZh3oT5bIIlGVm40kfFFtJV4eGpdks5qHkZrgaJpZM4HPfem.