On Fri, Apr 15, 2022 at 10:09 PM 'Wen Bo (Bill) Li' via grpc.io < [email protected]> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oNEJ0K9ophkbDjDeOU7mqVVyiPNJd%2BjkduuGGkX83m7qw%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
