Be warned, the deadline can become out of date, and it will be hard to change. A 5 second deadline may have been appropriate at one point, but it could change. You would have a hard time fixing it. One thing you might be interested in is Service Config ( https://github.com/grpc/grpc/blob/master/doc/service_config.md ) which allow you to describe the timeouts for your methods. This happens automatically, and comes as part of the DNS name resolution (it arrives as a TXT dns record). I don't know how widely implemented it is today, but it will eventually be.
On Wed, May 31, 2017 at 10:34 AM, Ryan Michela <[email protected]> wrote: > I really like the idea of using a proto option to communicate intended > deadlines for each operation. As an API publisher, that is a great way to > communicate to my consumers an SLA around operation response times. > > I'm imagining the interceptor could apply a deadline according to a > hierarchy: > 1. If the request already has a deadline set, use that, otherwise > 2. If the method has a deadline proto option, use that, otherwise > 3. If the service has a deadline proto option, use that, otherwise > 4. If a global maximum deadline has been set, use that > > Explicit request deadlines and global maximum deadlines are set by the > consumer, so if they are tighter than the proto's SLA, they should > override. There should also be a flag to indicate that a global deadline > can explicitly relax an SLA. > > On Wed, May 31, 2017 at 10:09 AM, 'Carl Mastrangelo' via grpc.io < > [email protected]> wrote: > >> Personally I would use an interceptor if there aren't many different many >> different kinds of methods. >> >> Another option is to put the deadline in the proto file (assuming you are >> using protobuf), as a method option >> <https://github.com/google/protobuf/blob/master/src/google/protobuf/descriptor.proto#L611>. >> This would need special handling to make sure you still inherit the >> deadline from the context, but you could read that from the interceptor >> easily. >> >> On Wednesday, May 31, 2017 at 12:49:21 AM UTC-7, Ryan Michela wrote: >>> >>> As indicated in this thread >>> <https://github.com/grpc/grpc-java/issues/1495>, a fresh deadline >>> should be created for every call. What is the best way to override the >>> default deadline for a Client so that every request uses a fresh deadline >>> with the same duration? >>> >>> Should I create a ClientInterceptor to fiddle with >>> CallOptions.withDeadlineAfter() for every request? >>> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "grpc.io" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/to >> pic/grpc-io/vykkmkIdMEM/unsubscribe. >> To unsubscribe from this group and all its topics, 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/ms >> gid/grpc-io/66faf6e5-2fbe-4745-a9bc-9f77bb1c3027%40googlegroups.com >> <https://groups.google.com/d/msgid/grpc-io/66faf6e5-2fbe-4745-a9bc-9f77bb1c3027%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/CAAcqB%2BsnoNRkt%3D39Sg9nsRFnH_87B__sbFUaageOdg%2BXg%3DXP2w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
