Ok, I did not find that previous message at all clarifying but I did find this one clarifying.
Yes, I believe the consensus is sentinel values like -1 and 0 should be eliminated. The value should carry a consistent meaning based on the unit of the value. If you think about it then there is really no special case of 0 (zero) when considered in the specified unit. It's zero iterations, zero seconds, or zero whatever. Negative numbers tend to be meaningless and should not be allowed. Infinity is also meaningless as there is nearly never a time when infinity is meant literally. 0 for example, a sleep for 0s would sleep for at least zero seconds, effectively not sleeping. A wait for 0s would be wait for at least 0 seconds before giving up, effectively give up immediately if the operation can't be completed without additional waiting or blocking. An iteration of 0 times would iterate over some operation zero times, effectively not at all. N for example, a sleep for Ns would sleep for at least N seconds. A wait for Ns would wait for at least N seconds for the operation to complete without additional waiting or blocking. An iteration of N times would iterate over some operation N times. Forever/All/Infinity, a sleep for seconds::max seconds would sleep for at least seconds::max seconds (at least 292 years), effectively forever. A wait for seconds::max seconds would wait for at least seconds::max seconds for the operation to complete without additional waiting or blocking, effectively forever. An iteration of std::numeric_limits<std::size_t>::max() times is by definition the max any container could store for read or writing of the results of the operation, effectively infinity. Or if just want to execute infinitely then considering 292 years was our duration infinite then std::numeric_limits<std::size_t>::max() works out to 2 operations per nanosecond, and since current CPU instructions are still measured in the microseconds we are safe for a while, not to mention that you will likely reboot in 292 years. -Jake On Wed, Sep 6, 2017 at 2:00 PM Mark Hanson <mhan...@pivotal.io> wrote: > 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> <(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 > >
