Hi, To clarify, the original email was to discuss the concept of overloading a number to mean infinity. The example cited was one where we were using -1 to mean all. While the example case was decided (remove the function), the basic question was not answered. I attempted in the previous email to summarize the general impression I was getting from people, which was that -1 to indicate infinity was undesirable.
This is a ubiquitous construct, used in socket api for example, so I think it is good to have a clear answers, but there have not been any. Hence the clarification. Thanks, Mark > On Sep 6, 2017, at 11:11 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > > I really am not following what you are trying to say. > > I think too many side conversations have muddied this original thread. The > question was about tries, lets keep focused on retries and not transition > the conversation to timeouts. > > As it relates to retries the consensus was get rid of it because it is more > appropriately handled by the current timeout APIs. > > If we need a thread about timeouts and their values then let's start a new > thread. > > -Jake > > On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson <mhan...@pivotal.io > <mailto:mhan...@pivotal.io>> wrote: > >> So the basic challenge here is for specific API, do we want to focus on >> providing a >> wait forever approach or just use the standard MAX_UNSIGNED and duration. >> I >> think that variable delay is something someone would implement in their own >> API >> and would not be done in the public API where consistency is valuable. I >> could be >> wrong in that belief. >> >> Further, it is sounding like a move away from overloading is the desired >> direction. >> Do we have any points against it?? >> >> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <mst...@pivotal.io> wrote: >> >>> We would certainly rather have the time-out set correctly, but one of the >>> things I've noticed is, sometimes there is just one query or one function >>> that takes a really long time, and because we keep retrying it with the >>> same timeout, it keeps timing out each retry. It would probably be much >>> smarter to use some sort of increasing timeout on the retries until we >> give >>> up. >>> >>> -- >>> Mike Stolz >>> Principal Engineer, GemFire Product Manager >>> Mobile: +1-631-835-4771 <(631)%20835-4771> >>> >>> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mhan...@pivotal.io >>> <mailto: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> < >> http://developerweb.net/ <http://developerweb.net/> >>>> viewtopic.php?id=3196> >>>>> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jbarr...@pivotal.io >>>>> <mailto: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 >>>>>> <mailto: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 >>>>>>> <mailto: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 >>>>>>>> <mailto: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 >>>>>>>>> <mailto: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 <mailto:jbarr...@pivotal.io>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson < >> mhan...@pivotal.io <mailto: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
