I can also see why the user doing the retries themselves has value. As a lowest common denominator approach, pulling the API is sound.
On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhan...@pivotal.io> wrote: > 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 >> > >
