You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First off: gRPC Gateway is awesome. We've been using it in Prod since time immortal.
We're currently adding gRPC timeouts throughout our stack, to make sure that hanging connections don't happen. grpc-timeout is a first class citizen in all gRPC implementations (see http://www.grpc.io/docs/guides/wire.html), and in case of gRPC-Go it is propagated using the context.Deadline in the gRPC client.
We tries enabling deadliens by passing a context.WithTimeout through RegisterMyFooServiceHandler, but unfortunately this lead to all our REST-originating gRPC requests to timeout immediately. That's because context.WithTimeout is implemented through context.WithDeadline from time.Now() of the server initialization :(
Unfortunately gRPC ClientConn doesn't support default context timeouts, so we want to work around it as follows:
We'd be happy to send in a patch that would:
in runtime.AnnotateContext extract a header Grpc-Timeout and set it into the context.WithTimeout
in absense of the Grpc-Timeout header, it'd use a static variable that controls the timeout runtime.DefaultTimeout = 0 (similar to runtime.HTTPError), which by default would disable the behaviour
What do you think? We're happy to provide this as a PR :)
The text was updated successfully, but these errors were encountered:
First off: gRPC Gateway is awesome. We've been using it in Prod since time immortal.
We're currently adding gRPC timeouts throughout our stack, to make sure that hanging connections don't happen.
grpc-timeout
is a first class citizen in all gRPC implementations (see http://www.grpc.io/docs/guides/wire.html), and in case of gRPC-Go it is propagated using thecontext.Deadline
in the gRPC client.We tries enabling deadliens by passing a
context.WithTimeout
throughRegisterMyFooServiceHandler
, but unfortunately this lead to all our REST-originating gRPC requests to timeout immediately. That's becausecontext.WithTimeout
is implemented throughcontext.WithDeadline
fromtime.Now()
of the server initialization :(Unfortunately gRPC ClientConn doesn't support default context timeouts, so we want to work around it as follows:
We'd be happy to send in a patch that would:
runtime.AnnotateContext
extract a headerGrpc-Timeout
and set it into thecontext.WithTimeout
Grpc-Timeout
header, it'd use a static variable that controls the timeoutruntime.DefaultTimeout = 0
(similar toruntime.HTTPError
), which by default would disable the behaviourWhat do you think? We're happy to provide this as a PR :)
The text was updated successfully, but these errors were encountered: