Hi. Is there a preferred way of implementing server side timeouts with the generated Go gRPC code? I'm using bidirectional streaming, with the extended request tied to a database transaction. I need to ensure database transactions are not held open more than a few seconds.
Doing this in Go, my best option seems to be to create a new context using context.WithTimeout(stream.Context(), dur) and using that. If I use this context when beginning the transaction, it will cause the transaction to rollback on the timeout. This does mean that the gRPC handler may keep running for some time, blocked on a stream.Recv or similar. So I can also use a goroutine for the main body of my handler, and wait of either the goroutine to complete or my context to be cancelled. Technically this would leak the goroutine I think (if blocked on stream.Recv or similar), although I think all that should clean up when the stream.Context() gets cancelled. An alternative might be to wrap the stream, using channels for sending and receiving messages rather than blocking calls, and allowing me to block until either a message is sent/received or the context cancelled. But I would either need to wrap every generated ServerStream or lose compile time type checking. I still get (I think benign) leaked goroutines as above. Or maybe there is something built in to the gRPC library that I missed? -- 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/ef5f3555-85be-4930-8e17-d17bcdf20dbe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
