On Friday, July 7, 2017 at 3:11:01 AM UTC-7, [email protected] wrote:
> 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. > I would recommend this. I'm having a bit of trouble understanding where the problem comes in. Are you performing these transactions in a goroutine, with the main service handler continually receiving requests and forking goroutines to handle them? 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. > Yes, stream.Recv() will unblock when the stream is terminated, so I wouldn't worry about this. 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. > That seems reasonable, too. Note that stream.Send and Recv aren't thread-safe, so you may only have one call of Send or Recv (each) outstanding at any time. If you are performing multiple operations concurrently, you'll need to synchronize the sending of the results somehow already. On Tuesday, July 11, 2017 at 2:26:21 AM UTC-7, [email protected] wrote: > > I've also tried installing an inTapHandle, which adds a timeout to the > context. Unfortunately with this approach, it seems that this shuts down > communication too early and no error returned to the client, which can > leave a client hanging indefinitely trying to receive a message. > That behavior does not sound intentional. If you have a reproducible case that demonstrates this, please file an issue on github. The client should see the deadline exceeded error (but possibly with code=unknown). Does this approach help with your problem, though? Are you only performing one operation per RPC? If you are trying to maintain a long-running stream and apply a shorter deadline to individual operations, then I don't think this would be appropriate, as the context returned applies to the entire stream, not each message. Thanks, Doug -- 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/b0e45ce7-1fa3-428c-abb2-c4a2f60694ff%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
