That is a really good point. Does the retry attempts even make sense anymore?
Does the Java client still have it? If so would it make sense to deprecate it there too? -Jake Sent from my iPhone > On Aug 30, 2017, at 8:36 PM, Dan Smith <dsm...@pivotal.io> 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 >>> >>
