None of the time spent performing the request is deterministic that’s why there are timeouts. I don’t follow your rational for claiming it complicated to code.
> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mhan...@pivotal.io> wrote: > > The only problem with that is the time to connect to another server is > non-deterministic. So, the code one would have to write to enable this would > involve a select and a bit of not fun code, but in general could be not very > useful as an API. > > I would say the lowest common denominator approach or the server based > approach is better. > > Just two cents. > > Thanks, > Mark >> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: >> >> I believe what Bruce was saying is that the behavior should be covered by >> timeouts not iteration attempts. If the client is able to successfully send >> the command to a server but a failure occurs waiting for a reply we would >> not retry. If the client is unable to send the request to a sever because >> the connection closes then we would try the next server, and the next, up >> to the timeout value. >> >>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mhan...@pivotal.io> wrote: >>> >>> 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 >>>>> >>>> >>>> >>> >
