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)
@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:
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 /