Just don't break existing users. Timeouts are tricky, and we have lots of users who have tuned them very carefully over the years.
-- Mike Stolz Principal Engineer, GemFire Product Manager Mobile: +1-631-835-4771 On Wed, Sep 6, 2017 at 1:18 PM, Mark Hanson <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 > > > > On Fri, Sep 1, 2017 at 2:07 PM, 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 > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >> > > > > > > > > >
