Replied under your GitHub comment. On Thu, Mar 21, 2019 at 5:44 PM <[email protected]> wrote:
> Thanks for the feedback, all of that makes sense. Using your feedback, I > think I came across a design that will work for my application, but I'd be > curious to hear your feedback on it (especially the potential post-forking > of subprocesses): > https://github.com/grpc/grpc/issues/16001#issuecomment-475439137 > > It's manageable and convoluted, my primary concern is if post-forking > subprocesses outside the scope of the gRPC servicer will cause any issues > with the gRPC servicer itself. > > On Tuesday, March 19, 2019 at 12:42:00 PM UTC-7, Lidi Zheng wrote: >> >> Your second post has a tiny typo I think. To pass a Python function as >> parameter, you don't need the parentheses: >> >> context.add_callback(context.cancel) >> >> Also, the callbacks added to the context will only execute after the gRPC >> termination. By that time, the "context.cancel" will be a no-op. >> >> About your first question regarding to deadline. The deadline exceeded in >> client-side will cancel the server-side request, but it is not cancelled >> automatically since there is no (legit) way in Python to terminate a >> running thread. If you would like to terminate your server task, please >> explicitly check the "is_active()" function in servicer context. >> >> Hope this will answer your questions :) >> >> >> >> >> >> >> On Tue, Mar 19, 2019 at 10:32 AM <[email protected]> wrote: >> >>> In addition, it seems like the callback functionality should be able >>> handle this through something like this ... >>> >>> Server pseudo-code: >>> >>> def Server(self, request_iterator, context): >>> context.add_callback(context.cancel()) >>> for request in request_iterator: >>> pass >>> >>> for _ in range(10): >>> time.sleep(1) >>> >>> print(context.is_active()) >>> print('still running!') >>> return test_pb2.Response() >>> >>> ... however, this immediately cancels the RPC, which seems to disagree >>> with the intended behavior described in the documentation: >>> https://grpc.io/grpc/python/grpc.html#grpc.RpcContext.add_callback >>> >>> On Tuesday, March 19, 2019 at 9:48:53 AM UTC-7, [email protected] >>> wrote: >>>> >>>> I want to verify some behavior in the Python code -- are timeouts only >>>> respected while receiving requests and not after requests have been >>>> received (but RPC is not finished)? Here's an example that uses a >>>> client-streaming RPC: >>>> >>>> Server pseudo-code: >>>> >>>> def Server(self, request_iterator, context): >>>> for request in request_iterator: >>>> pass >>>> >>>> for _ in range(10): >>>> time.sleep(1) >>>> >>>> print(context.is_active()) >>>> print('still running!') >>>> return test_pb2.Response() >>>> >>>> >>>> Client pseudo-code: >>>> >>>> def yielder(): >>>> for _ in range(20): >>>> yield test_pb2.Request() >>>> >>>> stub = test_pb2_grpc.TestStub(channel) >>>> response = stub.Server(yielder(), timeout=5) >>>> print(response) >>>> >>>> >>>> What happens is that the server will receive all the requests streams >>>> and while performing an operation, the timeout will pass and context will >>>> be inactive -- however, the RPC never aborts (i.e. the server will print >>>> 'still running!'). Is this intended behavior? I would expect that the >>>> server to stop processing after the timeout has elapsed. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "grpc.io" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/grpc-io. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/grpc-io/a9d19d24-75d0-459f-ac51-c15a4d02422e%40googlegroups.com >>> <https://groups.google.com/d/msgid/grpc-io/a9d19d24-75d0-459f-ac51-c15a4d02422e%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at https://groups.google.com/group/grpc-io. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/8c50e920-e6d3-4194-a1c3-2b53f4c52ce0%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/8c50e920-e6d3-4194-a1c3-2b53f4c52ce0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAMC1%3Djfz0nA6j4QJwYE5zzPJDw9jpMk1guwqVDn%3DAvPvgRWw5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
