I think the setRetryAttempts really harks back to the case that Bruce was
alluding to in which the server goes down. Which is the one valid case for
this kind of API in theory. Are we say that in that case we don't retry?
Seems like we are making the API a little less nice for people.
As a developer using an API, I want to do as little as possible and get the
most robust solution possible. This seems to go the wrong direction of that
kind of intent in a way. I want the client to automatically try every
server. I don't ever want to configure the value. I could limit with this
API and force it to never retry or I could cause it to retry more times
than I care for it to.  If we are going to get rid of this API in
particular, I would favor having it automatically try some number of
servers or all, but not retrying at all would not be my choice.

On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jbarr...@pivotal.io> wrote:

> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mhan...@pivotal.io> wrote:
>
> > I would have to go looking, but the key concept is that this is a bigger
> > problem.
> >
> > interval such as the time between retries....
> > wait as in how long to wait for a response...
> >
>
> All time intervals should be expressed in terms of std::chrono::duration
> values. A value of std::chrono::duration::zero means don't wait. I would
> suggest that a negative time not be allowed and that some very large,
> MAXINT, value could take the place of "forever". There is a ticket already
> open and in progress to replace all time based values with std::chrono.
>
>
> > retry as how many times to retry after a failure
> > attempts as in how many times to do a thing before giving up
> > Set of objects as in the setRetryAttempts code which , will try a number
> of
> > servers before giving up. where n is the number, -1 equals all, and 0
> means
> > (1 server, no retries).
> >
>
> If there are other examples of "iteration" then we should consider them
> based on what they iterate. I think the consensus on setRetryAttempts is to
> abolish it.
>
> -Jake
>

Reply via email to