Penn, thanks for the answer! Does it make sense to introduce another, shorter "deadline" for individual attempt and let grpc code to retry the request while keeping original deadline for the whole request possibly consisting of several retries ?
On Tuesday, November 6, 2018 at 11:19:35 AM UTC-8, Penn (Dapeng) Zhang wrote: > > Retry is already implemented (except hedging support) in v1.16.1, but > there is no other document than the spec yet, because there are some > caveats for the time being: (1) users need manage to disable census stats > and tracing when enabling retry,(2) there are some caveats for using > service config. In next release, v1.17.0, enabling retry will automatically > disable census. > > As for DEADLINE_EXCEEDED, it does not make sense to retry at the library > level, because a retry attempt would immediately exceed the deadline of the > RPC. Users could implement application level retry for DEADLINE_EXCEEDED by > themselves by making a new RPC. > > On Monday, November 5, 2018 at 12:55:42 PM UTC-8, David M wrote: >> >> I am trying to find a document describing grpc java retry behavioral. >> All I was able to find is this proposal : >> https://github.com/grpc/proposal/blob/master/A6-client-retries.md >> It's not clear what is already implemented. >> >> Thanks! >> > -- 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/748acd50-fea2-4d48-bc56-b3be0f87a004%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
