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... 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). On Thu, Aug 31, 2017 at 11:17 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > Mark, > > Can you give concrete examples in the API? > > On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson <mhan...@pivotal.io> wrote: > > > This basic problem exists with the following cases. > > Interval: to do something at an interval > > Wait: to wait a certain length of time > > Retry: to retry a certain number of times > > Attempts: to make a certain number of attempts (similar to retry) > > Sets of objects: to iterate through an unscoped set of objects. > > > > On Thu, Aug 31, 2017 at 11:04 AM, Jacob Barrett <jbarr...@pivotal.io> > > wrote: > > > > > I should have scoped it to the native API. > > > > > > > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt < > bschucha...@pivotal.io > > > > > > wrote: > > > > > > > > The DistributedLockService uses -1/0/n > > > > > > > > > > > >> On 8/31/17 10:21 AM, Jacob Barrett wrote: > > > >> In relation to this particular example you provided the discussion > of > > > removing it is valid as an alternative to fixing it. > > > >> > > > >> Are there other examples of this -1/0/n parameter style we should > > > discuss? > > > >> > > > >> -Jake > > > >> > > > >> > > > >> Sent from my iPhone > > > >> > > > >>> On Aug 31, 2017, at 10:15 AM, Mark Hanson <mhan...@pivotal.io> > > wrote: > > > >>> > > > >>> As I understand it here, the question is when the first server is > no > > > longer > > > >>> available, do we retry on another server. I would say the answer is > > > clearly > > > >>> yes and we in the name of controlling load want to have an API that > > > >>> controls the timing of how that is done. The customer can say no > > > retries > > > >>> and they can right their own........ > > > >>> > > > >>> This is a little bit off the topic of the much larger topic though. > > The > > > >>> reason I was told to send this email was to broach the larger > > > discussion of > > > >>> iteration and the overloading to use -1 to mean infinite. At least > > > that is > > > >>> my understanding... > > > >>> > > > >>> > > > >>> On Thu, Aug 31, 2017 at 9:32 AM, Udo Kohlmeyer < > > ukohlme...@pivotal.io> > > > >>> wrote: > > > >>> > > > >>>> +1 to removing retry, > > > >>>> > > > >>>> Imo, the retry should made the responsibility of the submitting > > > >>>> application. When an operation fails, the user should have to > decide > > > if > > > >>>> they should retry or not. It should not be default behavior of a > > > connection > > > >>>> pool. > > > >>>> > > > >>>> --Udo > > > >>>> > > > >>>> > > > >>>> > > > >>>>> On 8/31/17 09:26, Dan Smith wrote: > > > >>>>> > > > >>>>> The java client does still have a retry-attempts setting - it's > > > pretty > > > >>>>> much > > > >>>>> the same as the C++ API. > > > >>>>> > > > >>>>> I agree with Bruce though, I think the current retry behavior is > > not > > > >>>>> ideal. > > > >>>>> I think it only really makes sense for the client to retry an > > > operation > > > >>>>> that it actually sent to the server if the server stops > responding > > to > > > >>>>> pings. The believe the current retry behavior just waits the > > > read-timeout > > > >>>>> and then retries the operation on a new server. > > > >>>>> > > > >>>>> -Dan > > > >>>>> > > > >>>>> On Thu, Aug 31, 2017 at 8:08 AM, Bruce Schuchardt < > > > bschucha...@pivotal.io > > > >>>>> wrote: > > > >>>>> > > > >>>>> Does anyone have a good argument for clients retrying operations? > > I > > > can > > > >>>>>> see doing that if the server has died but otherwise it just > > > overloads the > > > >>>>>> servers. > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 8/30/17 8:36 PM, Dan Smith wrote: > > > >>>>>> > > > >>>>>> In general, I think we need making the configuration of geode > less > > > >>>>>>> complex, > > > >>>>>>> not more. > > > >>>>>>> > > > >>>>>>> As far as retry-attempts goes, maybe the best thing to do is to > > > get rid > > > >>>>>>> of > > > >>>>>>> it. The P2P layer has no such concept. I don't think users > should > > > really > > > >>>>>>> have to care about how many servers an operation is attempted > > > against. A > > > >>>>>>> user may want to specify how long an operation is allowed to > > take, > > > but > > > >>>>>>> that > > > >>>>>>> could be better specified with an operation timeout rather than > > the > > > >>>>>>> current > > > >>>>>>> read-timeout + retry-attempts. > > > >>>>>>> > > > >>>>>>> -Dan > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> On Wed, Aug 30, 2017 at 2:08 PM, Patrick Rhomberg < > > > prhomb...@pivotal.io > > > >>>>>>> wrote: > > > >>>>>>> > > > >>>>>>> Personally, I don't much like sentinel values, even if they > have > > > their > > > >>>>>>> > > > >>>>>>>> occasional use. > > > >>>>>>>> > > > >>>>>>>> Do we need to provide an authentic infinite value? 64-bit > > MAXINT > > > is > > > >>>>>>>> nearly > > > >>>>>>>> 10 quintillion. At 10GHz, that still takes almost three > years. > > > If > > > >>>>>>>> each > > > >>>>>>>> retry takes as much as 10ms, we're still looking at "retry for > > as > > > long > > > >>>>>>>> as > > > >>>>>>>> the earth has existed." 32-bit's is much more attainable, of > > > course, > > > >>>>>>>> but I > > > >>>>>>>> think the point stands -- if you need to retry that much, > > > something > > > >>>>>>>> else > > > >>>>>>>> is > > > >>>>>>>> very wrong. > > > >>>>>>>> > > > >>>>>>>> In the more general sense, I struggle to think of a context > > where > > > an > > > >>>>>>>> authentic infinity is meaningfully distinct in application > from > > a > > > >>>>>>>> massive > > > >>>>>>>> finite like MAXINT. But I could be wrong and would love to > hear > > > what > > > >>>>>>>> other > > > >>>>>>>> people think. > > > >>>>>>>> > > > >>>>>>>> On Wed, Aug 30, 2017 at 1:26 PM, Mark Hanson < > > mhan...@pivotal.io> > > > >>>>>>>> wrote: > > > >>>>>>>> > > > >>>>>>>> Hi All, > > > >>>>>>>> > > > >>>>>>>>> *Question: how should we deal in a very forward and clean > > > fashion with > > > >>>>>>>>> > > > >>>>>>>>> the > > > >>>>>>>> implicit ambiguity of -1 or all, or infinite, or forever?* > > > >>>>>>>>> > > > >>>>>>>>> *Background:* > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> We are looking to get some feedback on the subject of > > > >>>>>>>>> > > > >>>>>>>>> infinite/all/forever > > > >>>>>>>> in the geode/geode-native code. > > > >>>>>>>>> > > > >>>>>>>>> In looking at the code, we see an example function, > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> setRetryAttempts > > > >>>>>>>>> <https://github.com/apache/geode-native/blob/ > > > >>>>>>>>> 006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/ > > > >>>>>>>>> geode/PoolFactory.hpp#L327>() > > > >>>>>>>>> [1] currently -1 means try all servers before failing. 0 > means > > > try 1 > > > >>>>>>>>> > > > >>>>>>>>> server > > > >>>>>>>> before failing, and a number greater than 0 means try number > of > > > servers > > > >>>>>>>>> +1 > > > >>>>>>>> before failing. In the case of setRetryAttempts, we don’t know > > > how many > > > >>>>>>>>> servers there are. This means that -1 for "All" servers has > no > > > >>>>>>>>> relation > > > >>>>>>>>> > > > >>>>>>>>> to > > > >>>>>>>> the actual number of servers that we have. Perhaps > > > setRetryAttempts > > > >>>>>>>>> could > > > >>>>>>>>> be renamed to setNumberOfAttempts to clarify as well, but the > > > problem > > > >>>>>>>>> > > > >>>>>>>>> still > > > >>>>>>>> stands... > > > >>>>>>>>> > > > >>>>>>>>> *Discussion:* > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> In an attempt to provide the best code possible to the geode > > > >>>>>>>>> community, > > > >>>>>>>>> there has been some discussion of the use of > > > infinite/all/forever as > > > >>>>>>>>> an > > > >>>>>>>>> overload of a count. Often -1 indicates infinite, while 0 > > > indicates > > > >>>>>>>>> > > > >>>>>>>>> never, > > > >>>>>>>> and 1 to MAXINT, inclusive, indicates a count. > > > >>>>>>>>> > > > >>>>>>>>> There are three obvious approaches to solve the problem of > the > > > >>>>>>>>> > > > >>>>>>>>> overloading > > > >>>>>>>> of -1. The first approach is do nothing… Status quo. > > > >>>>>>>>> > > > >>>>>>>>> The second approach to clarify things would be to create an > > > >>>>>>>>> enumeration > > > >>>>>>>>> that would be passed in as well as the number or an object.. > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> struct Retries > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> typedef enum { eINFINITE, eCOUNT, eNONE} eCount; > > > >>>>>>>>> > > > >>>>>>>>> eCount approach; > > > >>>>>>>>> > > > >>>>>>>>> unsigned int count; > > > >>>>>>>>> > > > >>>>>>>>> }; > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> The third approach would be to pass a continue object of some > > > sort > > > >>>>>>>>> such > > > >>>>>>>>> that it tells you if it is ok to continue through the use of > an > > > >>>>>>>>> > > > >>>>>>>>> algorithm. > > > >>>>>>>> An example would be > > > >>>>>>>>> > > > >>>>>>>>> class Continue > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> virtual bool Continue() = 0; > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> class InfiniteContinue : public Continue > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> bool Continue() > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> return true; > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Continue co = InfiniteContinue; > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> while( co.Continue() ) > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> //do a thing > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> Another example would be a Continue limited to 5 let’s say, > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> class CountContinue : public Continue > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> private: > > > >>>>>>>>> > > > >>>>>>>>> int count; > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> public: > > > >>>>>>>>> > > > >>>>>>>>> CountContinue(int count) > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> this.count = count; > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> bool Continue() > > > >>>>>>>>> > > > >>>>>>>>> { > > > >>>>>>>>> > > > >>>>>>>>> return count— > 0; > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> } > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> In both of these cases what is happening is that the > algorithm > > is > > > >>>>>>>>> being > > > >>>>>>>>> outsourced. > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> *Conclusion:* > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> We are putting this out, to start a discussion on the best > way > > > to move > > > >>>>>>>>> > > > >>>>>>>>> this > > > >>>>>>>> forward… *What do people think? What direction would be the > best > > > going > > > >>>>>>>>> forward?* > > > >>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>>> [1] > > > >>>>>>>>> https://github.com/apache/geode-native/blob/ > > > >>>>>>>>> > > > >>>>>>>>> 006df0e70eeb481ef5e9e821dba005 > > > >>>>>>>> 0dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327 > > > >>>>>>>>> > > > >>>>>>>>> > > > > > > > > > >
