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 > > >>>>>>>>> > > >>>>>>>>> > > > > > >
