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