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