Remove retry attempts option and use existing timeouts as sole abort mechanism.
If you -1 please include constructive reasoning. -Jake > On Sep 1, 2017, at 11:07 AM, Mark Hanson <mhan...@pivotal.io> wrote: > > I actually don’t really have a strong opinion one way or the other. I get > both approaches. If we want to tailor the code to use a timeout instead of > retry attempts I guess that is fine. It seems kind of like we are > perpetuating the same API problem, that the LCD approach alleviates, but ok. > > It is more complicated to code because now you need to push everything > through poll or select. Such as the connect. Not that that is a bad thing, > because it is not. It is just more complicated. > > Thanks, > Mark > > http://developerweb.net/viewtopic.php?id=3196 > <http://developerweb.net/viewtopic.php?id=3196> >> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jbarr...@pivotal.io> wrote: >> >> 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 >>>>>>> >>>>>> >>>>>> >>>>> >>> >
