Okay, thanks. It looks like Context is more generic in client disconnecting from the server compared to ServerCall. In this case, I will use Context for our service.
On Monday, April 18, 2022 at 10:53:27 AM UTC-4 Eric Anderson wrote: > On Fri, Apr 15, 2022 at 10:09 PM 'Wen Bo (Bill) Li' via grpc.io < > grp...@googlegroups.com> wrote: > >> If this is the new approach, what would be the new best practice in terms >> of code implementation on detecting client disconnection (using the >> workaround you provided above)? >> > > It's not really a new vs old approach. Both approaches co-exist. The > ServerCall-based one has a callback that won't run concurrently with other > ServerCall.Listener/StreamObserver callbacks. That makes it very convenient > for non-thread-safe usage. The Context one is good for code needing a > callback via another thread, and is more generic and can apply to non-gRPC > and nested usages. It shouldn't ordinarily matter which of the two > isCancelled() methods you use in your specific code, with the exception of > this bug and that Context will always become cancelled at the end of the > RPC while the ServerCall one only becomes cancelled if the RPC was > cancelled. > -- 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 grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/1594d0e4-b4d4-4f4d-9337-e25bcc5d1fb5n%40googlegroups.com.
