You should track the err after each update, and if non-nil, just return… why keep trying the further updates in that loop.
It is also trivial too - to not even attempt the next loop if it has been less than N ms since the last error. According to your pseudo code, you already have the ‘server available’ status. > On Nov 20, 2018, at 9:22 PM, [email protected] wrote: > > GRPC Version: 1.3.9 > Platform: Windows > > I'm working on a prototype application that periodically calculates data and > then in a multi-step process pushes the data to a server. The design is that > the server doesn't need to be up or can go down mid process. The client will > not block (or block as little as possible) between updates if there is > problem pushing data. > > A simple model for the client would be: > Loop Until Done > { > Calculate Data > If Server Available and No Error Begin Update > If Server Available and No Error UpdateX (Optional) > If Server Available and No Error UpdateY (Optional) > If Server Available and No Error UpdateZ (Optional) > If Server Available and No Error End Update > } > > The client doesn't care if the server is available but if it is should push > data, if any errors skip everything else until next update. > > The problem is that if I make an call on the client (and the server isn't > available) the first fails very quickly (~1sec) and the rest take a "long" > time, ~20sec. It looks like this is due to the reconnect backoff time. I > tried setting the GRPC_ARG_MAX_RECONNECT_BACKOFF_MS on the channel args to a > lower value (2000) but that didn't have any positive affect. > > I tried using GetState(true) on the channel to determine if we need to skip > an update. This call fails very quickly but never seems to get out of the > transient failure state after the server was started (waited for over 60 > seconds). On the documentation it looked like the param for GetState only > affects if the channel was in the idle state to attempt a reconnect. > > What is the best way to achieve the functionality we'd like? > > I noticed there was a new GRPC_ARG_MIN_RECONNECT_BACKOFF_MS option added in a > later version of grpc, would that cause the grpc call to "fail fast" if I > upgraded and set that to a low value ~1sec? > > Is there a better way to handle this situation in general? > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/grpc-io > <https://groups.google.com/group/grpc-io>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/9fb7bf54-88fa-4781-8864-c9b2b06d5f0e%40googlegroups.com > > <https://groups.google.com/d/msgid/grpc-io/9fb7bf54-88fa-4781-8864-c9b2b06d5f0e%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <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/A62C8426-45F1-46E6-A7FC-07FA640CC17D%40earthlink.net. For more options, visit https://groups.google.com/d/optout.
