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


Reply via email to