Python Basics Tutorial claims you need to sleep-loop where you should actually call wait_for_termination()

[MohamedKari]

Issue description
The Python language guide states:

Because start() does not block you may need to sleep-loop if there is nothing else for your code to do while serving.

where should actually call wait_for_termination(). If you indeed do sleep-loop, you'll block the main thread and get weird errors, e. g. Connection reset by peer.

see https://github.com/grpc/grpc.io/blob/master/content/docs/languages/python/basics.md#L310

Steps to reproduce the issue

def serve():
    server = grpc.server(ThreadPoolExecutor(max_workers=1))

    inpainting_service_pb2_grpc.add_InpainterServicer_to_server(
        InpainterServicer(), 
        server)

    server.add_insecure_port("[::]:50051")
    server.start()

serve()
while True:
    time.sleep(1)

Expected behavior

Because `start()` does not block make sure to call `wait_for_termination()` if there is nothing else for your code to do while serving.

[MohamedKari]

Hi, just noticed that both approaches work (wait_for_termination() as well as sleep-looping) but in the code sample in the "Steps to reproduce the issue" indicated above, the server object gets disposed immediately after exiting the function.

It lies in the nature of calling wait_for_termination that you need a reference to the server object. Therefore, it seems "more foolproof" to use.

[chalin]

@ejona86 - can you respond to this or suggest who could? cc @jtattermusch

[ejona86]

Calling @grpc/grpc-python-team! (Richard or Lidi, did that seem to work well as a bat signal? I wonder if we should do something like that more often.)

[ejona86]

Hmm... or I guess to avoid lots of spam it would be better to use the triage routing rotation, which would mean Richard would be selected.

[gnossen]

Yes. This tutorial was written well before wait_for_termination was introduced. We updated all of the in-repo examples, but it looks like we missed this reference. I'll get together a PR to modernize this tutorial.

[gnossen]

@MohamedKari However, Connection reset by peer errors are not expected when using a sleep loop like that. The sleep loop should still be valid; just not the most optimal. Any such errors are likely unrelated to the sleeping. If you continue seeing them, I suggest you file an issue at https://github.com/grpc/grpc.

[MohamedKari]

Thanks for the clarification in the tutorial!

---

For the record:
@gnossen The problem of the connection reset by peer was that I was sleeping outside of the function scope. Upon leaving the function, the ref count of the server object goes to 0 and the server object is destroyed.

def serve():
    server = grpc.server(ThreadPoolExecutor(max_workers=1))

    inpainting_service_pb2_grpc.add_InpainterServicer_to_server(
        InpainterServicer(), 
        server)

    server.add_insecure_port("[::]:50051")
    server.start()
    return server

# WORKS AS EXPECTED
server = serve() # keeps reference to the server object

while True:
     time.sleep(1) #  1 sec or 1000 secs, doesn't seem to matter with respect to latency


# DOESN'T WORK (leads to 'Connection reset by peer' or 'Socket closed' exception on client side)
serve() # doesn't keep a reference to server object, no reference left upon return, created server object gets cleaned up 

while True:
     time.sleep(1) # server broken anyway, hopelessly sleeping without possibility of parole

So, probably expected behavior. Thanks for the info, though.