You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Mark Hanson <mh...@pivotal.io> on 2017/08/30 20:26:51 UTC
[Discuss] Use of -1 as Infinite/All for retry related functions...
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/006df0e70eeb481ef5e9e821dba0050dee9c6893/cppcache/include/geode/PoolFactory.hpp#L327
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
-1 for using -1!
Another option is to change the factory API to:
withRetryAttempts(uint32_t retryAttempts)
Will attempt no more than `retryAttempts`, may be less if all available
servers are exhausted.
withRetryAttemptsAllServers()
Will retry on all servers.
withoutRetryAttempts()
Will not retry. Same behavior as `withRetryAttempts(0)`.
-Jake
On Wed, Aug 30, 2017 at 2:09 PM Patrick Rhomberg <pr...@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 <mh...@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
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Udo Kohlmeyer <ud...@apache.org>.
I think with the retry one has to distinguish between:
1. currently running tasks that have not yet completed (current timeout
behavior)
2. tasks that have failed because the server died.
In case #1, we currently have the ability to compound any load error, by
forwarding the request to the cluster again, thus just adding
unnecessary load. In this case we should NEVER just randomly retry.
In case #2, the client should retry another server because the original
request might have been lost, never completed, or completed but not yet
notified on result. THIS would be the ONLY case were an auto retry
makes sense....
--Udo
On 8/31/17 11:10, Mark Hanson 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 <jb...@pivotal.io> wrote:
>
>> I should have scoped it to the native API.
>>
>>> On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <bs...@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 <mh...@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 <uk...@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 <
>> bschuchardt@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 <
>> prhomberg@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 <mh...@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
>>>>>>>>>>>
Re: [VOTE] Use of -1 as Infinite/All for retry related functions...
Posted by Bruce Schuchardt <bs...@pivotal.io>.
+1
On 9/1/17 11:19 AM, Jacob Barrett wrote:
> Remove retry attempts option and use existing timeouts as sole abort mechanism.
>
> If you -1 please include constructive reasoning.
>
> -Jake
>
>
>
>> On Sep 1, 2017, at 11:07 AM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>> I actually don’t really have a strong opinion one way or the other. I get both approaches. If we want to tailor the code to use a timeout instead of retry attempts I guess that is fine. It seems kind of like we are perpetuating the same API problem, that the LCD approach alleviates, but ok.
>>
>> It is more complicated to code because now you need to push everything through poll or select. Such as the connect. Not that that is a bad thing, because it is not. It is just more complicated.
>>
>> Thanks,
>> Mark
>>
>> http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/viewtopic.php?id=3196>
>>> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> None of the time spent performing the request is deterministic that’s why there are timeouts. I don’t follow your rational for claiming it complicated to code.
>>>
>>>> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>>
>>>> The only problem with that is the time to connect to another server is non-deterministic. So, the code one would have to write to enable this would involve a select and a bit of not fun code, but in general could be not very useful as an API.
>>>>
>>>> I would say the lowest common denominator approach or the server based approach is better.
>>>>
>>>> Just two cents.
>>>>
>>>> Thanks,
>>>> Mark
>>>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>>>
>>>>> I believe what Bruce was saying is that the behavior should be covered by
>>>>> timeouts not iteration attempts. If the client is able to successfully send
>>>>> the command to a server but a failure occurs waiting for a reply we would
>>>>> not retry. If the client is unable to send the request to a sever because
>>>>> the connection closes then we would try the next server, and the next, up
>>>>> to the timeout value.
>>>>>
>>>>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>
>>>>>> I can also see why the user doing the retries themselves has value. As a
>>>>>> lowest common denominator approach, pulling the API is sound.
>>>>>>
>>>>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>>
>>>>>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>>>>>> alluding to in which the server goes down. Which is the one valid case
>>>>>> for
>>>>>>> this kind of API in theory. Are we say that in that case we don't retry?
>>>>>>> Seems like we are making the API a little less nice for people.
>>>>>>> As a developer using an API, I want to do as little as possible and get
>>>>>>> the most robust solution possible. This seems to go the wrong direction
>>>>>> of
>>>>>>> that kind of intent in a way. I want the client to automatically try
>>>>>> every
>>>>>>> server. I don't ever want to configure the value. I could limit with this
>>>>>>> API and force it to never retry or I could cause it to retry more times
>>>>>>> than I care for it to. If we are going to get rid of this API in
>>>>>>> particular, I would favor having it automatically try some number of
>>>>>>> servers or all, but not retrying at all would not be my choice.
>>>>>>>
>>>>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>>>>
>>>>>>>>> I would have to go looking, but the key concept is that this is a
>>>>>> bigger
>>>>>>>>> problem.
>>>>>>>>>
>>>>>>>>> interval such as the time between retries....
>>>>>>>>> wait as in how long to wait for a response...
>>>>>>>>>
>>>>>>>> All time intervals should be expressed in terms of std::chrono::duration
>>>>>>>> values. A value of std::chrono::duration::zero means don't wait. I would
>>>>>>>> suggest that a negative time not be allowed and that some very large,
>>>>>>>> MAXINT, value could take the place of "forever". There is a ticket
>>>>>> already
>>>>>>>> open and in progress to replace all time based values with std::chrono.
>>>>>>>>
>>>>>>>>
>>>>>>>>> retry as how many times to retry after a failure
>>>>>>>>> attempts as in how many times to do a thing before giving up
>>>>>>>>> Set of objects as in the setRetryAttempts code which , will try a
>>>>>>>> number of
>>>>>>>>> servers before giving up. where n is the number, -1 equals all, and 0
>>>>>>>> means
>>>>>>>>> (1 server, no retries).
>>>>>>>>>
>>>>>>>> If there are other examples of "iteration" then we should consider them
>>>>>>>> based on what they iterate. I think the consensus on setRetryAttempts is
>>>>>>>> to
>>>>>>>> abolish it.
>>>>>>>>
>>>>>>>> -Jake
>>>>>>>>
>>>>>>>
[VOTE] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
Remove retry attempts option and use existing timeouts as sole abort mechanism.
If you -1 please include constructive reasoning.
-Jake
> On Sep 1, 2017, at 11:07 AM, Mark Hanson <mh...@pivotal.io> wrote:
>
> I actually don’t really have a strong opinion one way or the other. I get both approaches. If we want to tailor the code to use a timeout instead of retry attempts I guess that is fine. It seems kind of like we are perpetuating the same API problem, that the LCD approach alleviates, but ok.
>
> It is more complicated to code because now you need to push everything through poll or select. Such as the connect. Not that that is a bad thing, because it is not. It is just more complicated.
>
> Thanks,
> Mark
>
> http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/viewtopic.php?id=3196>
>> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> None of the time spent performing the request is deterministic that’s why there are timeouts. I don’t follow your rational for claiming it complicated to code.
>>
>>> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>
>>> The only problem with that is the time to connect to another server is non-deterministic. So, the code one would have to write to enable this would involve a select and a bit of not fun code, but in general could be not very useful as an API.
>>>
>>> I would say the lowest common denominator approach or the server based approach is better.
>>>
>>> Just two cents.
>>>
>>> Thanks,
>>> Mark
>>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>>
>>>> I believe what Bruce was saying is that the behavior should be covered by
>>>> timeouts not iteration attempts. If the client is able to successfully send
>>>> the command to a server but a failure occurs waiting for a reply we would
>>>> not retry. If the client is unable to send the request to a sever because
>>>> the connection closes then we would try the next server, and the next, up
>>>> to the timeout value.
>>>>
>>>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>
>>>>> I can also see why the user doing the retries themselves has value. As a
>>>>> lowest common denominator approach, pulling the API is sound.
>>>>>
>>>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>
>>>>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>>>>> alluding to in which the server goes down. Which is the one valid case
>>>>> for
>>>>>> this kind of API in theory. Are we say that in that case we don't retry?
>>>>>> Seems like we are making the API a little less nice for people.
>>>>>> As a developer using an API, I want to do as little as possible and get
>>>>>> the most robust solution possible. This seems to go the wrong direction
>>>>> of
>>>>>> that kind of intent in a way. I want the client to automatically try
>>>>> every
>>>>>> server. I don't ever want to configure the value. I could limit with this
>>>>>> API and force it to never retry or I could cause it to retry more times
>>>>>> than I care for it to. If we are going to get rid of this API in
>>>>>> particular, I would favor having it automatically try some number of
>>>>>> servers or all, but not retrying at all would not be my choice.
>>>>>>
>>>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
>>>>>> wrote:
>>>>>>
>>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>>>
>>>>>>>> I would have to go looking, but the key concept is that this is a
>>>>> bigger
>>>>>>>> problem.
>>>>>>>>
>>>>>>>> interval such as the time between retries....
>>>>>>>> wait as in how long to wait for a response...
>>>>>>>>
>>>>>>>
>>>>>>> All time intervals should be expressed in terms of std::chrono::duration
>>>>>>> values. A value of std::chrono::duration::zero means don't wait. I would
>>>>>>> suggest that a negative time not be allowed and that some very large,
>>>>>>> MAXINT, value could take the place of "forever". There is a ticket
>>>>> already
>>>>>>> open and in progress to replace all time based values with std::chrono.
>>>>>>>
>>>>>>>
>>>>>>>> retry as how many times to retry after a failure
>>>>>>>> attempts as in how many times to do a thing before giving up
>>>>>>>> Set of objects as in the setRetryAttempts code which , will try a
>>>>>>> number of
>>>>>>>> servers before giving up. where n is the number, -1 equals all, and 0
>>>>>>> means
>>>>>>>> (1 server, no retries).
>>>>>>>>
>>>>>>>
>>>>>>> If there are other examples of "iteration" then we should consider them
>>>>>>> based on what they iterate. I think the consensus on setRetryAttempts is
>>>>>>> to
>>>>>>> abolish it.
>>>>>>>
>>>>>>> -Jake
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
To be sure, if we find particular API bad/unclear/misnamed, a change is
always easy to justify.
On Wed, Sep 6, 2017 at 4:37 PM, Mark Hanson <mh...@pivotal.io> wrote:
> To play devil's advocate,
>
> I have dealt with -1 for years in network development among other places.
> In just about every case, it has not been a problem. The only cases I can
> think of where it has gotten weird in recent memory are badly designed API
> such as the retry attempts because the API should have really been called
> attempts... Why is this a big enough problem to invest in? C# a very new
> language has added the same -1 behavior, so obviously it does not cause
> major problems. While I support separate API for clarity, what justifies
> the expense(time and testing)?? One might not call this a technical debt
> issue, considering all the other users of this approach.
>
> Again just playing devil's advocate here.
>
> Thanks,
> Mark
>
>
>
> On Wed, Sep 6, 2017 at 3:26 PM, Anthony Baker <ab...@pivotal.io> wrote:
>
>> Perfect!
>>
>> > On Sep 6, 2017, at 3:13 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>> >
>> > And this is where the details are more useful than the abstract. I
>> think if
>> > we focus more on specific API methods and answer the questions for each
>> or
>> > those we will spend less time going back and forth on the use of
>> sentinel
>> > values.
>> >
>> > X.doSomethingUntil(10s); <- do something, give up after at least 10s
>> > X.doSomething(); <- do something, never give up
>> >
>> > Very clear and no sentinel values.
>> >
>> > Y.doSomethingWithLimit(10); <- do it 10 times
>> > Y.doSomething(); <- do it forever
>> >
>> > Very clear and no sentinel values.
>> >
>> > -Jake
>> >
>> >
>> > On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker <ab...@pivotal.io> wrote:
>> >
>> >>
>> >>> On Sep 6, 2017, at 2:29 PM, Jacob Barrett <jb...@pivotal.io>
>> wrote:
>> >>>
>> >>> Ok, I did not find that previous message at all clarifying but I did
>> find
>> >>> this one clarifying.
>> >>
>> >> I think the objective is to provide a clear and understandable API.
>> >>
>> >> IMO, a ReallyBigNumber is not easily readable. Is the user’s intent to
>> >> wait XXX time or forever? Why not provide a constant value / enum to
>> >> signal intent?
>> >>
>> >> There are so many usages of “0 as infinity” throughout the internets
>> that
>> >> I personally don’t find it all that confusing.
>> >>
>> >> Anthony
>> >>
>> >>
>>
>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
On Wed, Sep 6, 2017 at 4:37 PM Mark Hanson <mh...@pivotal.io> wrote:
> C# a very new
> language has added the same -1 behavior, so obviously it does not cause
> major problems.
Can you cite references here?
The major problem comes when dealing with units. When we change the time
based methods to take units to remove ambiguity -1 is no longer a trivial
solution. The simplest explanation for that is -1s != -1ms, so you can't
simply check for -1 sentinel values. You could say that all values less
than 0s are infinite but why make things like this in modern times. We have
better ways to express meaningful values.
-Jake
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
To play devil's advocate,
I have dealt with -1 for years in network development among other places.
In just about every case, it has not been a problem. The only cases I can
think of where it has gotten weird in recent memory are badly designed API
such as the retry attempts because the API should have really been called
attempts... Why is this a big enough problem to invest in? C# a very new
language has added the same -1 behavior, so obviously it does not cause
major problems. While I support separate API for clarity, what justifies
the expense(time and testing)?? One might not call this a technical debt
issue, considering all the other users of this approach.
Again just playing devil's advocate here.
Thanks,
Mark
On Wed, Sep 6, 2017 at 3:26 PM, Anthony Baker <ab...@pivotal.io> wrote:
> Perfect!
>
> > On Sep 6, 2017, at 3:13 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > And this is where the details are more useful than the abstract. I think
> if
> > we focus more on specific API methods and answer the questions for each
> or
> > those we will spend less time going back and forth on the use of sentinel
> > values.
> >
> > X.doSomethingUntil(10s); <- do something, give up after at least 10s
> > X.doSomething(); <- do something, never give up
> >
> > Very clear and no sentinel values.
> >
> > Y.doSomethingWithLimit(10); <- do it 10 times
> > Y.doSomething(); <- do it forever
> >
> > Very clear and no sentinel values.
> >
> > -Jake
> >
> >
> > On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker <ab...@pivotal.io> wrote:
> >
> >>
> >>> On Sep 6, 2017, at 2:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >>>
> >>> Ok, I did not find that previous message at all clarifying but I did
> find
> >>> this one clarifying.
> >>
> >> I think the objective is to provide a clear and understandable API.
> >>
> >> IMO, a ReallyBigNumber is not easily readable. Is the user’s intent to
> >> wait XXX time or forever? Why not provide a constant value / enum to
> >> signal intent?
> >>
> >> There are so many usages of “0 as infinity” throughout the internets
> that
> >> I personally don’t find it all that confusing.
> >>
> >> Anthony
> >>
> >>
>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Anthony Baker <ab...@pivotal.io>.
Perfect!
> On Sep 6, 2017, at 3:13 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> And this is where the details are more useful than the abstract. I think if
> we focus more on specific API methods and answer the questions for each or
> those we will spend less time going back and forth on the use of sentinel
> values.
>
> X.doSomethingUntil(10s); <- do something, give up after at least 10s
> X.doSomething(); <- do something, never give up
>
> Very clear and no sentinel values.
>
> Y.doSomethingWithLimit(10); <- do it 10 times
> Y.doSomething(); <- do it forever
>
> Very clear and no sentinel values.
>
> -Jake
>
>
> On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker <ab...@pivotal.io> wrote:
>
>>
>>> On Sep 6, 2017, at 2:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> Ok, I did not find that previous message at all clarifying but I did find
>>> this one clarifying.
>>
>> I think the objective is to provide a clear and understandable API.
>>
>> IMO, a ReallyBigNumber is not easily readable. Is the user’s intent to
>> wait XXX time or forever? Why not provide a constant value / enum to
>> signal intent?
>>
>> There are so many usages of “0 as infinity” throughout the internets that
>> I personally don’t find it all that confusing.
>>
>> Anthony
>>
>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
And this is where the details are more useful than the abstract. I think if
we focus more on specific API methods and answer the questions for each or
those we will spend less time going back and forth on the use of sentinel
values.
X.doSomethingUntil(10s); <- do something, give up after at least 10s
X.doSomething(); <- do something, never give up
Very clear and no sentinel values.
Y.doSomethingWithLimit(10); <- do it 10 times
Y.doSomething(); <- do it forever
Very clear and no sentinel values.
-Jake
On Wed, Sep 6, 2017 at 2:50 PM Anthony Baker <ab...@pivotal.io> wrote:
>
> > On Sep 6, 2017, at 2:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > Ok, I did not find that previous message at all clarifying but I did find
> > this one clarifying.
>
> I think the objective is to provide a clear and understandable API.
>
> IMO, a ReallyBigNumber is not easily readable. Is the user’s intent to
> wait XXX time or forever? Why not provide a constant value / enum to
> signal intent?
>
> There are so many usages of “0 as infinity” throughout the internets that
> I personally don’t find it all that confusing.
>
> Anthony
>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Anthony Baker <ab...@pivotal.io>.
> On Sep 6, 2017, at 2:29 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> Ok, I did not find that previous message at all clarifying but I did find
> this one clarifying.
I think the objective is to provide a clear and understandable API.
IMO, a ReallyBigNumber is not easily readable. Is the user’s intent to wait XXX time or forever? Why not provide a constant value / enum to signal intent?
There are so many usages of “0 as infinity” throughout the internets that I personally don’t find it all that confusing.
Anthony
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
Ok, I did not find that previous message at all clarifying but I did find
this one clarifying.
Yes, I believe the consensus is sentinel values like -1 and 0 should be
eliminated. The value should carry a consistent meaning based on the unit
of the value. If you think about it then there is really no special case of
0 (zero) when considered in the specified unit. It's zero iterations, zero
seconds, or zero whatever. Negative numbers tend to be meaningless and
should not be allowed. Infinity is also meaningless as there is nearly
never a time when infinity is meant literally.
0 for example, a sleep for 0s would sleep for at least zero seconds,
effectively not sleeping. A wait for 0s would be wait for at least 0
seconds before giving up, effectively give up immediately if the operation
can't be completed without additional waiting or blocking. An iteration of
0 times would iterate over some operation zero times, effectively not at
all.
N for example, a sleep for Ns would sleep for at least N seconds. A wait
for Ns would wait for at least N seconds for the operation to complete
without additional waiting or blocking. An iteration of N times would
iterate over some operation N times.
Forever/All/Infinity, a sleep for seconds::max seconds would sleep for at
least seconds::max seconds (at least 292 years), effectively forever. A
wait for seconds::max seconds would wait for at least seconds::max seconds
for the operation to complete without additional waiting or blocking,
effectively forever. An iteration of
std::numeric_limits<std::size_t>::max() times is by definition the max any
container could store for read or writing of the results of the operation,
effectively infinity. Or if just want to execute infinitely then
considering 292 years was our duration infinite then
std::numeric_limits<std::size_t>::max() works out to 2 operations per
nanosecond, and since current CPU instructions are still measured in the
microseconds we are safe for a while, not to mention that you will likely
reboot in 292 years.
-Jake
On Wed, Sep 6, 2017 at 2:00 PM Mark Hanson <mh...@pivotal.io> wrote:
> Hi,
>
> To clarify, the original email was to discuss the concept of overloading a
> number to mean infinity.
> The example cited was one where we were using -1 to mean all. While the
> example case was decided (remove the function), the basic question was not
> answered. I attempted in the previous email to summarize the general
> impression I was getting from people, which was that -1 to indicate
> infinity was undesirable.
>
> This is a ubiquitous construct, used in socket api for example, so I think
> it is good to have a clear answers, but there have not been any. Hence the
> clarification.
>
> Thanks,
> Mark
>
>
>
> > On Sep 6, 2017, at 11:11 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > I really am not following what you are trying to say.
> >
> > I think too many side conversations have muddied this original thread.
> The
> > question was about tries, lets keep focused on retries and not transition
> > the conversation to timeouts.
> >
> > As it relates to retries the consensus was get rid of it because it is
> more
> > appropriately handled by the current timeout APIs.
> >
> > If we need a thread about timeouts and their values then let's start a
> new
> > thread.
> >
> > -Jake
> >
> > On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson <mhanson@pivotal.io <mailto:
> mhanson@pivotal.io>> wrote:
> >
> >> So the basic challenge here is for specific API, do we want to focus on
> >> providing a
> >> wait forever approach or just use the standard MAX_UNSIGNED and
> duration.
> >> I
> >> think that variable delay is something someone would implement in their
> own
> >> API
> >> and would not be done in the public API where consistency is valuable. I
> >> could be
> >> wrong in that belief.
> >>
> >> Further, it is sounding like a move away from overloading is the desired
> >> direction.
> >> Do we have any points against it??
> >>
> >> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <ms...@pivotal.io>
> wrote:
> >>
> >>> We would certainly rather have the time-out set correctly, but one of
> the
> >>> things I've noticed is, sometimes there is just one query or one
> function
> >>> that takes a really long time, and because we keep retrying it with the
> >>> same timeout, it keeps timing out each retry. It would probably be much
> >>> smarter to use some sort of increasing timeout on the retries until we
> >> give
> >>> up.
> >>>
> >>> --
> >>> Mike Stolz
> >>> Principal Engineer, GemFire Product Manager
> >>> Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> >>>
> >>> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mhanson@pivotal.io
> <ma...@pivotal.io>> wrote:
> >>>
> >>>> I actually don’t really have a strong opinion one way or the other. I
> >> get
> >>>> both approaches. If we want to tailor the code to use a timeout
> instead
> >>> of
> >>>> retry attempts I guess that is fine. It seems kind of like we are
> >>>> perpetuating the same API problem, that the LCD approach alleviates,
> >> but
> >>> ok.
> >>>>
> >>>> It is more complicated to code because now you need to push everything
> >>>> through poll or select. Such as the connect. Not that that is a bad
> >>> thing,
> >>>> because it is not. It is just more complicated.
> >>>>
> >>>> Thanks,
> >>>> Mark
> >>>>
> >>>> http://developerweb.net/viewtopic.php?id=3196 <
> http://developerweb.net/viewtopic.php?id=3196> <
> >> http://developerweb.net/ <http://developerweb.net/>
> >>>> viewtopic.php?id=3196>
> >>>>> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jbarrett@pivotal.io
> <ma...@pivotal.io>>
> >>> wrote:
> >>>>>
> >>>>> None of the time spent performing the request is deterministic that’s
> >>>> why there are timeouts. I don’t follow your rational for claiming it
> >>>> complicated to code.
> >>>>>
> >>>>>> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mhanson@pivotal.io
> <ma...@pivotal.io>>
> >> wrote:
> >>>>>>
> >>>>>> The only problem with that is the time to connect to another server
> >> is
> >>>> non-deterministic. So, the code one would have to write to enable
> this
> >>>> would involve a select and a bit of not fun code, but in general could
> >> be
> >>>> not very useful as an API.
> >>>>>>
> >>>>>> I would say the lowest common denominator approach or the server
> >> based
> >>>> approach is better.
> >>>>>>
> >>>>>> Just two cents.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Mark
> >>>>>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jbarrett@pivotal.io
> <ma...@pivotal.io>>
> >>>> wrote:
> >>>>>>>
> >>>>>>> I believe what Bruce was saying is that the behavior should be
> >>> covered
> >>>> by
> >>>>>>> timeouts not iteration attempts. If the client is able to
> >>> successfully
> >>>> send
> >>>>>>> the command to a server but a failure occurs waiting for a reply we
> >>>> would
> >>>>>>> not retry. If the client is unable to send the request to a sever
> >>>> because
> >>>>>>> the connection closes then we would try the next server, and the
> >>> next,
> >>>> up
> >>>>>>> to the timeout value.
> >>>>>>>
> >>>>>>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mhanson@pivotal.io
> <ma...@pivotal.io>>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>> I can also see why the user doing the retries themselves has
> >> value.
> >>>> As a
> >>>>>>>> lowest common denominator approach, pulling the API is sound.
> >>>>>>>>
> >>>>>>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhanson@pivotal.io
> <ma...@pivotal.io>
> >>>
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>> I think the setRetryAttempts really harks back to the case that
> >>>> Bruce was
> >>>>>>>>> alluding to in which the server goes down. Which is the one valid
> >>>> case
> >>>>>>>> for
> >>>>>>>>> this kind of API in theory. Are we say that in that case we don't
> >>>> retry?
> >>>>>>>>> Seems like we are making the API a little less nice for people.
> >>>>>>>>> As a developer using an API, I want to do as little as possible
> >> and
> >>>> get
> >>>>>>>>> the most robust solution possible. This seems to go the wrong
> >>>> direction
> >>>>>>>> of
> >>>>>>>>> that kind of intent in a way. I want the client to automatically
> >>> try
> >>>>>>>> every
> >>>>>>>>> server. I don't ever want to configure the value. I could limit
> >>> with
> >>>> this
> >>>>>>>>> API and force it to never retry or I could cause it to retry more
> >>>> times
> >>>>>>>>> than I care for it to. If we are going to get rid of this API in
> >>>>>>>>> particular, I would favor having it automatically try some number
> >>> of
> >>>>>>>>> servers or all, but not retrying at all would not be my choice.
> >>>>>>>>>
> >>>>>>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
> >>> jbarrett@pivotal.io <ma...@pivotal.io>>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <
> >> mhanson@pivotal.io <ma...@pivotal.io>>
> >>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I would have to go looking, but the key concept is that this
> >> is a
> >>>>>>>> bigger
> >>>>>>>>>>> problem.
> >>>>>>>>>>>
> >>>>>>>>>>> interval such as the time between retries....
> >>>>>>>>>>> wait as in how long to wait for a response...
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> All time intervals should be expressed in terms of
> >>>> std::chrono::duration
> >>>>>>>>>> values. A value of std::chrono::duration::zero means don't
> >> wait. I
> >>>> would
> >>>>>>>>>> suggest that a negative time not be allowed and that some very
> >>>> large,
> >>>>>>>>>> MAXINT, value could take the place of "forever". There is a
> >> ticket
> >>>>>>>> already
> >>>>>>>>>> open and in progress to replace all time based values with
> >>>> std::chrono.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> retry as how many times to retry after a failure
> >>>>>>>>>>> attempts as in how many times to do a thing before giving up
> >>>>>>>>>>> Set of objects as in the setRetryAttempts code which , will
> >> try a
> >>>>>>>>>> number of
> >>>>>>>>>>> servers before giving up. where n is the number, -1 equals all,
> >>>> and 0
> >>>>>>>>>> means
> >>>>>>>>>>> (1 server, no retries).
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> If there are other examples of "iteration" then we should
> >> consider
> >>>> them
> >>>>>>>>>> based on what they iterate. I think the consensus on
> >>>> setRetryAttempts is
> >>>>>>>>>> to
> >>>>>>>>>> abolish it.
> >>>>>>>>>>
> >>>>>>>>>> -Jake
>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Mark Hanson <mh...@pivotal.io>.
Hi,
To clarify, the original email was to discuss the concept of overloading a number to mean infinity.
The example cited was one where we were using -1 to mean all. While the example case was decided (remove the function), the basic question was not answered. I attempted in the previous email to summarize the general impression I was getting from people, which was that -1 to indicate infinity was undesirable.
This is a ubiquitous construct, used in socket api for example, so I think it is good to have a clear answers, but there have not been any. Hence the clarification.
Thanks,
Mark
> On Sep 6, 2017, at 11:11 AM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I really am not following what you are trying to say.
>
> I think too many side conversations have muddied this original thread. The
> question was about tries, lets keep focused on retries and not transition
> the conversation to timeouts.
>
> As it relates to retries the consensus was get rid of it because it is more
> appropriately handled by the current timeout APIs.
>
> If we need a thread about timeouts and their values then let's start a new
> thread.
>
> -Jake
>
> On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>> wrote:
>
>> So the basic challenge here is for specific API, do we want to focus on
>> providing a
>> wait forever approach or just use the standard MAX_UNSIGNED and duration.
>> I
>> think that variable delay is something someone would implement in their own
>> API
>> and would not be done in the public API where consistency is valuable. I
>> could be
>> wrong in that belief.
>>
>> Further, it is sounding like a move away from overloading is the desired
>> direction.
>> Do we have any points against it??
>>
>> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <ms...@pivotal.io> wrote:
>>
>>> We would certainly rather have the time-out set correctly, but one of the
>>> things I've noticed is, sometimes there is just one query or one function
>>> that takes a really long time, and because we keep retrying it with the
>>> same timeout, it keeps timing out each retry. It would probably be much
>>> smarter to use some sort of increasing timeout on the retries until we
>> give
>>> up.
>>>
>>> --
>>> Mike Stolz
>>> Principal Engineer, GemFire Product Manager
>>> Mobile: +1-631-835-4771 <(631)%20835-4771>
>>>
>>> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>> wrote:
>>>
>>>> I actually don’t really have a strong opinion one way or the other. I
>> get
>>>> both approaches. If we want to tailor the code to use a timeout instead
>>> of
>>>> retry attempts I guess that is fine. It seems kind of like we are
>>>> perpetuating the same API problem, that the LCD approach alleviates,
>> but
>>> ok.
>>>>
>>>> It is more complicated to code because now you need to push everything
>>>> through poll or select. Such as the connect. Not that that is a bad
>>> thing,
>>>> because it is not. It is just more complicated.
>>>>
>>>> Thanks,
>>>> Mark
>>>>
>>>> http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/viewtopic.php?id=3196> <
>> http://developerweb.net/ <http://developerweb.net/>
>>>> viewtopic.php?id=3196>
>>>>> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jbarrett@pivotal.io <ma...@pivotal.io>>
>>> wrote:
>>>>>
>>>>> None of the time spent performing the request is deterministic that’s
>>>> why there are timeouts. I don’t follow your rational for claiming it
>>>> complicated to code.
>>>>>
>>>>>> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>>
>> wrote:
>>>>>>
>>>>>> The only problem with that is the time to connect to another server
>> is
>>>> non-deterministic. So, the code one would have to write to enable this
>>>> would involve a select and a bit of not fun code, but in general could
>> be
>>>> not very useful as an API.
>>>>>>
>>>>>> I would say the lowest common denominator approach or the server
>> based
>>>> approach is better.
>>>>>>
>>>>>> Just two cents.
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
>>>>>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jbarrett@pivotal.io <ma...@pivotal.io>>
>>>> wrote:
>>>>>>>
>>>>>>> I believe what Bruce was saying is that the behavior should be
>>> covered
>>>> by
>>>>>>> timeouts not iteration attempts. If the client is able to
>>> successfully
>>>> send
>>>>>>> the command to a server but a failure occurs waiting for a reply we
>>>> would
>>>>>>> not retry. If the client is unable to send the request to a sever
>>>> because
>>>>>>> the connection closes then we would try the next server, and the
>>> next,
>>>> up
>>>>>>> to the timeout value.
>>>>>>>
>>>>>>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>>
>>>> wrote:
>>>>>>>>
>>>>>>>> I can also see why the user doing the retries themselves has
>> value.
>>>> As a
>>>>>>>> lowest common denominator approach, pulling the API is sound.
>>>>>>>>
>>>>>>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhanson@pivotal.io <ma...@pivotal.io>
>>>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> I think the setRetryAttempts really harks back to the case that
>>>> Bruce was
>>>>>>>>> alluding to in which the server goes down. Which is the one valid
>>>> case
>>>>>>>> for
>>>>>>>>> this kind of API in theory. Are we say that in that case we don't
>>>> retry?
>>>>>>>>> Seems like we are making the API a little less nice for people.
>>>>>>>>> As a developer using an API, I want to do as little as possible
>> and
>>>> get
>>>>>>>>> the most robust solution possible. This seems to go the wrong
>>>> direction
>>>>>>>> of
>>>>>>>>> that kind of intent in a way. I want the client to automatically
>>> try
>>>>>>>> every
>>>>>>>>> server. I don't ever want to configure the value. I could limit
>>> with
>>>> this
>>>>>>>>> API and force it to never retry or I could cause it to retry more
>>>> times
>>>>>>>>> than I care for it to. If we are going to get rid of this API in
>>>>>>>>> particular, I would favor having it automatically try some number
>>> of
>>>>>>>>> servers or all, but not retrying at all would not be my choice.
>>>>>>>>>
>>>>>>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
>>> jbarrett@pivotal.io <ma...@pivotal.io>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <
>> mhanson@pivotal.io <ma...@pivotal.io>>
>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I would have to go looking, but the key concept is that this
>> is a
>>>>>>>> bigger
>>>>>>>>>>> problem.
>>>>>>>>>>>
>>>>>>>>>>> interval such as the time between retries....
>>>>>>>>>>> wait as in how long to wait for a response...
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> All time intervals should be expressed in terms of
>>>> std::chrono::duration
>>>>>>>>>> values. A value of std::chrono::duration::zero means don't
>> wait. I
>>>> would
>>>>>>>>>> suggest that a negative time not be allowed and that some very
>>>> large,
>>>>>>>>>> MAXINT, value could take the place of "forever". There is a
>> ticket
>>>>>>>> already
>>>>>>>>>> open and in progress to replace all time based values with
>>>> std::chrono.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> retry as how many times to retry after a failure
>>>>>>>>>>> attempts as in how many times to do a thing before giving up
>>>>>>>>>>> Set of objects as in the setRetryAttempts code which , will
>> try a
>>>>>>>>>> number of
>>>>>>>>>>> servers before giving up. where n is the number, -1 equals all,
>>>> and 0
>>>>>>>>>> means
>>>>>>>>>>> (1 server, no retries).
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If there are other examples of "iteration" then we should
>> consider
>>>> them
>>>>>>>>>> based on what they iterate. I think the consensus on
>>>> setRetryAttempts is
>>>>>>>>>> to
>>>>>>>>>> abolish it.
>>>>>>>>>>
>>>>>>>>>> -Jake
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
I really am not following what you are trying to say.
I think too many side conversations have muddied this original thread. The
question was about tries, lets keep focused on retries and not transition
the conversation to timeouts.
As it relates to retries the consensus was get rid of it because it is more
appropriately handled by the current timeout APIs.
If we need a thread about timeouts and their values then let's start a new
thread.
-Jake
On Wed, Sep 6, 2017 at 10:19 AM Mark Hanson <mh...@pivotal.io> wrote:
> So the basic challenge here is for specific API, do we want to focus on
> providing a
> wait forever approach or just use the standard MAX_UNSIGNED and duration.
> I
> think that variable delay is something someone would implement in their own
> API
> and would not be done in the public API where consistency is valuable. I
> could be
> wrong in that belief.
>
> Further, it is sounding like a move away from overloading is the desired
> direction.
> Do we have any points against it??
>
> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <ms...@pivotal.io> wrote:
>
> > We would certainly rather have the time-out set correctly, but one of the
> > things I've noticed is, sometimes there is just one query or one function
> > that takes a really long time, and because we keep retrying it with the
> > same timeout, it keeps timing out each retry. It would probably be much
> > smarter to use some sort of increasing timeout on the retries until we
> give
> > up.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mh...@pivotal.io> wrote:
> >
> > > I actually don’t really have a strong opinion one way or the other. I
> get
> > > both approaches. If we want to tailor the code to use a timeout instead
> > of
> > > retry attempts I guess that is fine. It seems kind of like we are
> > > perpetuating the same API problem, that the LCD approach alleviates,
> but
> > ok.
> > >
> > > It is more complicated to code because now you need to push everything
> > > through poll or select. Such as the connect. Not that that is a bad
> > thing,
> > > because it is not. It is just more complicated.
> > >
> > > Thanks,
> > > Mark
> > >
> > > http://developerweb.net/viewtopic.php?id=3196 <
> http://developerweb.net/
> > > viewtopic.php?id=3196>
> > > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > > >
> > > > None of the time spent performing the request is deterministic that’s
> > > why there are timeouts. I don’t follow your rational for claiming it
> > > complicated to code.
> > > >
> > > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io>
> wrote:
> > > >>
> > > >> The only problem with that is the time to connect to another server
> is
> > > non-deterministic. So, the code one would have to write to enable this
> > > would involve a select and a bit of not fun code, but in general could
> be
> > > not very useful as an API.
> > > >>
> > > >> I would say the lowest common denominator approach or the server
> based
> > > approach is better.
> > > >>
> > > >> Just two cents.
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > >>>
> > > >>> I believe what Bruce was saying is that the behavior should be
> > covered
> > > by
> > > >>> timeouts not iteration attempts. If the client is able to
> > successfully
> > > send
> > > >>> the command to a server but a failure occurs waiting for a reply we
> > > would
> > > >>> not retry. If the client is unable to send the request to a sever
> > > because
> > > >>> the connection closes then we would try the next server, and the
> > next,
> > > up
> > > >>> to the timeout value.
> > > >>>
> > > >>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io>
> > > wrote:
> > > >>>>
> > > >>>> I can also see why the user doing the retries themselves has
> value.
> > > As a
> > > >>>> lowest common denominator approach, pulling the API is sound.
> > > >>>>
> > > >>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhanson@pivotal.io
> >
> > > wrote:
> > > >>>>>
> > > >>>>> I think the setRetryAttempts really harks back to the case that
> > > Bruce was
> > > >>>>> alluding to in which the server goes down. Which is the one valid
> > > case
> > > >>>> for
> > > >>>>> this kind of API in theory. Are we say that in that case we don't
> > > retry?
> > > >>>>> Seems like we are making the API a little less nice for people.
> > > >>>>> As a developer using an API, I want to do as little as possible
> and
> > > get
> > > >>>>> the most robust solution possible. This seems to go the wrong
> > > direction
> > > >>>> of
> > > >>>>> that kind of intent in a way. I want the client to automatically
> > try
> > > >>>> every
> > > >>>>> server. I don't ever want to configure the value. I could limit
> > with
> > > this
> > > >>>>> API and force it to never retry or I could cause it to retry more
> > > times
> > > >>>>> than I care for it to. If we are going to get rid of this API in
> > > >>>>> particular, I would favor having it automatically try some number
> > of
> > > >>>>> servers or all, but not retrying at all would not be my choice.
> > > >>>>>
> > > >>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
> > jbarrett@pivotal.io>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <
> mhanson@pivotal.io>
> > > wrote:
> > > >>>>>>>
> > > >>>>>>> I would have to go looking, but the key concept is that this
> is a
> > > >>>> bigger
> > > >>>>>>> problem.
> > > >>>>>>>
> > > >>>>>>> interval such as the time between retries....
> > > >>>>>>> wait as in how long to wait for a response...
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> All time intervals should be expressed in terms of
> > > std::chrono::duration
> > > >>>>>> values. A value of std::chrono::duration::zero means don't
> wait. I
> > > would
> > > >>>>>> suggest that a negative time not be allowed and that some very
> > > large,
> > > >>>>>> MAXINT, value could take the place of "forever". There is a
> ticket
> > > >>>> already
> > > >>>>>> open and in progress to replace all time based values with
> > > std::chrono.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> retry as how many times to retry after a failure
> > > >>>>>>> attempts as in how many times to do a thing before giving up
> > > >>>>>>> Set of objects as in the setRetryAttempts code which , will
> try a
> > > >>>>>> number of
> > > >>>>>>> servers before giving up. where n is the number, -1 equals all,
> > > and 0
> > > >>>>>> means
> > > >>>>>>> (1 server, no retries).
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> If there are other examples of "iteration" then we should
> consider
> > > them
> > > >>>>>> based on what they iterate. I think the consensus on
> > > setRetryAttempts is
> > > >>>>>> to
> > > >>>>>> abolish it.
> > > >>>>>>
> > > >>>>>> -Jake
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > >
> > >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Michael Stolz <ms...@pivotal.io>.
Just don't break existing users.
Timeouts are tricky, and we have lots of users who have tuned them very
carefully over the years.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
On Wed, Sep 6, 2017 at 1:18 PM, Mark Hanson <mh...@pivotal.io> wrote:
> So the basic challenge here is for specific API, do we want to focus on
> providing a
> wait forever approach or just use the standard MAX_UNSIGNED and duration.
> I
> think that variable delay is something someone would implement in their own
> API
> and would not be done in the public API where consistency is valuable. I
> could be
> wrong in that belief.
>
> Further, it is sounding like a move away from overloading is the desired
> direction.
> Do we have any points against it??
>
> On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <ms...@pivotal.io> wrote:
>
> > We would certainly rather have the time-out set correctly, but one of the
> > things I've noticed is, sometimes there is just one query or one function
> > that takes a really long time, and because we keep retrying it with the
> > same timeout, it keeps timing out each retry. It would probably be much
> > smarter to use some sort of increasing timeout on the retries until we
> give
> > up.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771
> >
> > On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mh...@pivotal.io> wrote:
> >
> > > I actually don’t really have a strong opinion one way or the other. I
> get
> > > both approaches. If we want to tailor the code to use a timeout instead
> > of
> > > retry attempts I guess that is fine. It seems kind of like we are
> > > perpetuating the same API problem, that the LCD approach alleviates,
> but
> > ok.
> > >
> > > It is more complicated to code because now you need to push everything
> > > through poll or select. Such as the connect. Not that that is a bad
> > thing,
> > > because it is not. It is just more complicated.
> > >
> > > Thanks,
> > > Mark
> > >
> > > http://developerweb.net/viewtopic.php?id=3196 <
> http://developerweb.net/
> > > viewtopic.php?id=3196>
> > > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > > >
> > > > None of the time spent performing the request is deterministic that’s
> > > why there are timeouts. I don’t follow your rational for claiming it
> > > complicated to code.
> > > >
> > > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io>
> wrote:
> > > >>
> > > >> The only problem with that is the time to connect to another server
> is
> > > non-deterministic. So, the code one would have to write to enable this
> > > would involve a select and a bit of not fun code, but in general could
> be
> > > not very useful as an API.
> > > >>
> > > >> I would say the lowest common denominator approach or the server
> based
> > > approach is better.
> > > >>
> > > >> Just two cents.
> > > >>
> > > >> Thanks,
> > > >> Mark
> > > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io>
> > > wrote:
> > > >>>
> > > >>> I believe what Bruce was saying is that the behavior should be
> > covered
> > > by
> > > >>> timeouts not iteration attempts. If the client is able to
> > successfully
> > > send
> > > >>> the command to a server but a failure occurs waiting for a reply we
> > > would
> > > >>> not retry. If the client is unable to send the request to a sever
> > > because
> > > >>> the connection closes then we would try the next server, and the
> > next,
> > > up
> > > >>> to the timeout value.
> > > >>>
> > > >>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io>
> > > wrote:
> > > >>>>
> > > >>>> I can also see why the user doing the retries themselves has
> value.
> > > As a
> > > >>>> lowest common denominator approach, pulling the API is sound.
> > > >>>>
> > > >>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mhanson@pivotal.io
> >
> > > wrote:
> > > >>>>>
> > > >>>>> I think the setRetryAttempts really harks back to the case that
> > > Bruce was
> > > >>>>> alluding to in which the server goes down. Which is the one valid
> > > case
> > > >>>> for
> > > >>>>> this kind of API in theory. Are we say that in that case we don't
> > > retry?
> > > >>>>> Seems like we are making the API a little less nice for people.
> > > >>>>> As a developer using an API, I want to do as little as possible
> and
> > > get
> > > >>>>> the most robust solution possible. This seems to go the wrong
> > > direction
> > > >>>> of
> > > >>>>> that kind of intent in a way. I want the client to automatically
> > try
> > > >>>> every
> > > >>>>> server. I don't ever want to configure the value. I could limit
> > with
> > > this
> > > >>>>> API and force it to never retry or I could cause it to retry more
> > > times
> > > >>>>> than I care for it to. If we are going to get rid of this API in
> > > >>>>> particular, I would favor having it automatically try some number
> > of
> > > >>>>> servers or all, but not retrying at all would not be my choice.
> > > >>>>>
> > > >>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
> > jbarrett@pivotal.io>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <
> mhanson@pivotal.io>
> > > wrote:
> > > >>>>>>>
> > > >>>>>>> I would have to go looking, but the key concept is that this
> is a
> > > >>>> bigger
> > > >>>>>>> problem.
> > > >>>>>>>
> > > >>>>>>> interval such as the time between retries....
> > > >>>>>>> wait as in how long to wait for a response...
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> All time intervals should be expressed in terms of
> > > std::chrono::duration
> > > >>>>>> values. A value of std::chrono::duration::zero means don't
> wait. I
> > > would
> > > >>>>>> suggest that a negative time not be allowed and that some very
> > > large,
> > > >>>>>> MAXINT, value could take the place of "forever". There is a
> ticket
> > > >>>> already
> > > >>>>>> open and in progress to replace all time based values with
> > > std::chrono.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>>> retry as how many times to retry after a failure
> > > >>>>>>> attempts as in how many times to do a thing before giving up
> > > >>>>>>> Set of objects as in the setRetryAttempts code which , will
> try a
> > > >>>>>> number of
> > > >>>>>>> servers before giving up. where n is the number, -1 equals all,
> > > and 0
> > > >>>>>> means
> > > >>>>>>> (1 server, no retries).
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>> If there are other examples of "iteration" then we should
> consider
> > > them
> > > >>>>>> based on what they iterate. I think the consensus on
> > > setRetryAttempts is
> > > >>>>>> to
> > > >>>>>> abolish it.
> > > >>>>>>
> > > >>>>>> -Jake
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > >
> > >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
So the basic challenge here is for specific API, do we want to focus on
providing a
wait forever approach or just use the standard MAX_UNSIGNED and duration.
I
think that variable delay is something someone would implement in their own
API
and would not be done in the public API where consistency is valuable. I
could be
wrong in that belief.
Further, it is sounding like a move away from overloading is the desired
direction.
Do we have any points against it??
On Fri, Sep 1, 2017 at 2:45 PM, Michael Stolz <ms...@pivotal.io> wrote:
> We would certainly rather have the time-out set correctly, but one of the
> things I've noticed is, sometimes there is just one query or one function
> that takes a really long time, and because we keep retrying it with the
> same timeout, it keeps timing out each retry. It would probably be much
> smarter to use some sort of increasing timeout on the retries until we give
> up.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> > I actually don’t really have a strong opinion one way or the other. I get
> > both approaches. If we want to tailor the code to use a timeout instead
> of
> > retry attempts I guess that is fine. It seems kind of like we are
> > perpetuating the same API problem, that the LCD approach alleviates, but
> ok.
> >
> > It is more complicated to code because now you need to push everything
> > through poll or select. Such as the connect. Not that that is a bad
> thing,
> > because it is not. It is just more complicated.
> >
> > Thanks,
> > Mark
> >
> > http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/
> > viewtopic.php?id=3196>
> > > On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> > >
> > > None of the time spent performing the request is deterministic that’s
> > why there are timeouts. I don’t follow your rational for claiming it
> > complicated to code.
> > >
> > >> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
> > >>
> > >> The only problem with that is the time to connect to another server is
> > non-deterministic. So, the code one would have to write to enable this
> > would involve a select and a bit of not fun code, but in general could be
> > not very useful as an API.
> > >>
> > >> I would say the lowest common denominator approach or the server based
> > approach is better.
> > >>
> > >> Just two cents.
> > >>
> > >> Thanks,
> > >> Mark
> > >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> > >>>
> > >>> I believe what Bruce was saying is that the behavior should be
> covered
> > by
> > >>> timeouts not iteration attempts. If the client is able to
> successfully
> > send
> > >>> the command to a server but a failure occurs waiting for a reply we
> > would
> > >>> not retry. If the client is unable to send the request to a sever
> > because
> > >>> the connection closes then we would try the next server, and the
> next,
> > up
> > >>> to the timeout value.
> > >>>
> > >>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io>
> > wrote:
> > >>>>
> > >>>> I can also see why the user doing the retries themselves has value.
> > As a
> > >>>> lowest common denominator approach, pulling the API is sound.
> > >>>>
> > >>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io>
> > wrote:
> > >>>>>
> > >>>>> I think the setRetryAttempts really harks back to the case that
> > Bruce was
> > >>>>> alluding to in which the server goes down. Which is the one valid
> > case
> > >>>> for
> > >>>>> this kind of API in theory. Are we say that in that case we don't
> > retry?
> > >>>>> Seems like we are making the API a little less nice for people.
> > >>>>> As a developer using an API, I want to do as little as possible and
> > get
> > >>>>> the most robust solution possible. This seems to go the wrong
> > direction
> > >>>> of
> > >>>>> that kind of intent in a way. I want the client to automatically
> try
> > >>>> every
> > >>>>> server. I don't ever want to configure the value. I could limit
> with
> > this
> > >>>>> API and force it to never retry or I could cause it to retry more
> > times
> > >>>>> than I care for it to. If we are going to get rid of this API in
> > >>>>> particular, I would favor having it automatically try some number
> of
> > >>>>> servers or all, but not retrying at all would not be my choice.
> > >>>>>
> > >>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <
> jbarrett@pivotal.io>
> > >>>>> wrote:
> > >>>>>
> > >>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io>
> > wrote:
> > >>>>>>>
> > >>>>>>> I would have to go looking, but the key concept is that this is a
> > >>>> bigger
> > >>>>>>> problem.
> > >>>>>>>
> > >>>>>>> interval such as the time between retries....
> > >>>>>>> wait as in how long to wait for a response...
> > >>>>>>>
> > >>>>>>
> > >>>>>> All time intervals should be expressed in terms of
> > std::chrono::duration
> > >>>>>> values. A value of std::chrono::duration::zero means don't wait. I
> > would
> > >>>>>> suggest that a negative time not be allowed and that some very
> > large,
> > >>>>>> MAXINT, value could take the place of "forever". There is a ticket
> > >>>> already
> > >>>>>> open and in progress to replace all time based values with
> > std::chrono.
> > >>>>>>
> > >>>>>>
> > >>>>>>> retry as how many times to retry after a failure
> > >>>>>>> attempts as in how many times to do a thing before giving up
> > >>>>>>> Set of objects as in the setRetryAttempts code which , will try a
> > >>>>>> number of
> > >>>>>>> servers before giving up. where n is the number, -1 equals all,
> > and 0
> > >>>>>> means
> > >>>>>>> (1 server, no retries).
> > >>>>>>>
> > >>>>>>
> > >>>>>> If there are other examples of "iteration" then we should consider
> > them
> > >>>>>> based on what they iterate. I think the consensus on
> > setRetryAttempts is
> > >>>>>> to
> > >>>>>> abolish it.
> > >>>>>>
> > >>>>>> -Jake
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Michael Stolz <ms...@pivotal.io>.
We would certainly rather have the time-out set correctly, but one of the
things I've noticed is, sometimes there is just one query or one function
that takes a really long time, and because we keep retrying it with the
same timeout, it keeps timing out each retry. It would probably be much
smarter to use some sort of increasing timeout on the retries until we give
up.
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771
On Fri, Sep 1, 2017 at 2:07 PM, Mark Hanson <mh...@pivotal.io> wrote:
> I actually don’t really have a strong opinion one way or the other. I get
> both approaches. If we want to tailor the code to use a timeout instead of
> retry attempts I guess that is fine. It seems kind of like we are
> perpetuating the same API problem, that the LCD approach alleviates, but ok.
>
> It is more complicated to code because now you need to push everything
> through poll or select. Such as the connect. Not that that is a bad thing,
> because it is not. It is just more complicated.
>
> Thanks,
> Mark
>
> http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/
> viewtopic.php?id=3196>
> > On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> >
> > None of the time spent performing the request is deterministic that’s
> why there are timeouts. I don’t follow your rational for claiming it
> complicated to code.
> >
> >> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
> >>
> >> The only problem with that is the time to connect to another server is
> non-deterministic. So, the code one would have to write to enable this
> would involve a select and a bit of not fun code, but in general could be
> not very useful as an API.
> >>
> >> I would say the lowest common denominator approach or the server based
> approach is better.
> >>
> >> Just two cents.
> >>
> >> Thanks,
> >> Mark
> >>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
> >>>
> >>> I believe what Bruce was saying is that the behavior should be covered
> by
> >>> timeouts not iteration attempts. If the client is able to successfully
> send
> >>> the command to a server but a failure occurs waiting for a reply we
> would
> >>> not retry. If the client is unable to send the request to a sever
> because
> >>> the connection closes then we would try the next server, and the next,
> up
> >>> to the timeout value.
> >>>
> >>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io>
> wrote:
> >>>>
> >>>> I can also see why the user doing the retries themselves has value.
> As a
> >>>> lowest common denominator approach, pulling the API is sound.
> >>>>
> >>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io>
> wrote:
> >>>>>
> >>>>> I think the setRetryAttempts really harks back to the case that
> Bruce was
> >>>>> alluding to in which the server goes down. Which is the one valid
> case
> >>>> for
> >>>>> this kind of API in theory. Are we say that in that case we don't
> retry?
> >>>>> Seems like we are making the API a little less nice for people.
> >>>>> As a developer using an API, I want to do as little as possible and
> get
> >>>>> the most robust solution possible. This seems to go the wrong
> direction
> >>>> of
> >>>>> that kind of intent in a way. I want the client to automatically try
> >>>> every
> >>>>> server. I don't ever want to configure the value. I could limit with
> this
> >>>>> API and force it to never retry or I could cause it to retry more
> times
> >>>>> than I care for it to. If we are going to get rid of this API in
> >>>>> particular, I would favor having it automatically try some number of
> >>>>> servers or all, but not retrying at all would not be my choice.
> >>>>>
> >>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
> >>>>> wrote:
> >>>>>
> >>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io>
> wrote:
> >>>>>>>
> >>>>>>> I would have to go looking, but the key concept is that this is a
> >>>> bigger
> >>>>>>> problem.
> >>>>>>>
> >>>>>>> interval such as the time between retries....
> >>>>>>> wait as in how long to wait for a response...
> >>>>>>>
> >>>>>>
> >>>>>> All time intervals should be expressed in terms of
> std::chrono::duration
> >>>>>> values. A value of std::chrono::duration::zero means don't wait. I
> would
> >>>>>> suggest that a negative time not be allowed and that some very
> large,
> >>>>>> MAXINT, value could take the place of "forever". There is a ticket
> >>>> already
> >>>>>> open and in progress to replace all time based values with
> std::chrono.
> >>>>>>
> >>>>>>
> >>>>>>> retry as how many times to retry after a failure
> >>>>>>> attempts as in how many times to do a thing before giving up
> >>>>>>> Set of objects as in the setRetryAttempts code which , will try a
> >>>>>> number of
> >>>>>>> servers before giving up. where n is the number, -1 equals all,
> and 0
> >>>>>> means
> >>>>>>> (1 server, no retries).
> >>>>>>>
> >>>>>>
> >>>>>> If there are other examples of "iteration" then we should consider
> them
> >>>>>> based on what they iterate. I think the consensus on
> setRetryAttempts is
> >>>>>> to
> >>>>>> abolish it.
> >>>>>>
> >>>>>> -Jake
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Mark Hanson <mh...@pivotal.io>.
I actually don’t really have a strong opinion one way or the other. I get both approaches. If we want to tailor the code to use a timeout instead of retry attempts I guess that is fine. It seems kind of like we are perpetuating the same API problem, that the LCD approach alleviates, but ok.
It is more complicated to code because now you need to push everything through poll or select. Such as the connect. Not that that is a bad thing, because it is not. It is just more complicated.
Thanks,
Mark
http://developerweb.net/viewtopic.php?id=3196 <http://developerweb.net/viewtopic.php?id=3196>
> On Aug 31, 2017, at 3:47 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> None of the time spent performing the request is deterministic that’s why there are timeouts. I don’t follow your rational for claiming it complicated to code.
>
>> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>> The only problem with that is the time to connect to another server is non-deterministic. So, the code one would have to write to enable this would involve a select and a bit of not fun code, but in general could be not very useful as an API.
>>
>> I would say the lowest common denominator approach or the server based approach is better.
>>
>> Just two cents.
>>
>> Thanks,
>> Mark
>>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>>
>>> I believe what Bruce was saying is that the behavior should be covered by
>>> timeouts not iteration attempts. If the client is able to successfully send
>>> the command to a server but a failure occurs waiting for a reply we would
>>> not retry. If the client is unable to send the request to a sever because
>>> the connection closes then we would try the next server, and the next, up
>>> to the timeout value.
>>>
>>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>
>>>> I can also see why the user doing the retries themselves has value. As a
>>>> lowest common denominator approach, pulling the API is sound.
>>>>
>>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>>>
>>>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>>>> alluding to in which the server goes down. Which is the one valid case
>>>> for
>>>>> this kind of API in theory. Are we say that in that case we don't retry?
>>>>> Seems like we are making the API a little less nice for people.
>>>>> As a developer using an API, I want to do as little as possible and get
>>>>> the most robust solution possible. This seems to go the wrong direction
>>>> of
>>>>> that kind of intent in a way. I want the client to automatically try
>>>> every
>>>>> server. I don't ever want to configure the value. I could limit with this
>>>>> API and force it to never retry or I could cause it to retry more times
>>>>> than I care for it to. If we are going to get rid of this API in
>>>>> particular, I would favor having it automatically try some number of
>>>>> servers or all, but not retrying at all would not be my choice.
>>>>>
>>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
>>>>> wrote:
>>>>>
>>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>>
>>>>>>> I would have to go looking, but the key concept is that this is a
>>>> bigger
>>>>>>> problem.
>>>>>>>
>>>>>>> interval such as the time between retries....
>>>>>>> wait as in how long to wait for a response...
>>>>>>>
>>>>>>
>>>>>> All time intervals should be expressed in terms of std::chrono::duration
>>>>>> values. A value of std::chrono::duration::zero means don't wait. I would
>>>>>> suggest that a negative time not be allowed and that some very large,
>>>>>> MAXINT, value could take the place of "forever". There is a ticket
>>>> already
>>>>>> open and in progress to replace all time based values with std::chrono.
>>>>>>
>>>>>>
>>>>>>> retry as how many times to retry after a failure
>>>>>>> attempts as in how many times to do a thing before giving up
>>>>>>> Set of objects as in the setRetryAttempts code which , will try a
>>>>>> number of
>>>>>>> servers before giving up. where n is the number, -1 equals all, and 0
>>>>>> means
>>>>>>> (1 server, no retries).
>>>>>>>
>>>>>>
>>>>>> If there are other examples of "iteration" then we should consider them
>>>>>> based on what they iterate. I think the consensus on setRetryAttempts is
>>>>>> to
>>>>>> abolish it.
>>>>>>
>>>>>> -Jake
>>>>>>
>>>>>
>>>>>
>>>>
>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
None of the time spent performing the request is deterministic that’s why there are timeouts. I don’t follow your rational for claiming it complicated to code.
> On Aug 31, 2017, at 3:27 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> The only problem with that is the time to connect to another server is non-deterministic. So, the code one would have to write to enable this would involve a select and a bit of not fun code, but in general could be not very useful as an API.
>
> I would say the lowest common denominator approach or the server based approach is better.
>
> Just two cents.
>
> Thanks,
> Mark
>> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>>
>> I believe what Bruce was saying is that the behavior should be covered by
>> timeouts not iteration attempts. If the client is able to successfully send
>> the command to a server but a failure occurs waiting for a reply we would
>> not retry. If the client is unable to send the request to a sever because
>> the connection closes then we would try the next server, and the next, up
>> to the timeout value.
>>
>>> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>
>>> I can also see why the user doing the retries themselves has value. As a
>>> lowest common denominator approach, pulling the API is sound.
>>>
>>>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>>>
>>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>>> alluding to in which the server goes down. Which is the one valid case
>>> for
>>>> this kind of API in theory. Are we say that in that case we don't retry?
>>>> Seems like we are making the API a little less nice for people.
>>>> As a developer using an API, I want to do as little as possible and get
>>>> the most robust solution possible. This seems to go the wrong direction
>>> of
>>>> that kind of intent in a way. I want the client to automatically try
>>> every
>>>> server. I don't ever want to configure the value. I could limit with this
>>>> API and force it to never retry or I could cause it to retry more times
>>>> than I care for it to. If we are going to get rid of this API in
>>>> particular, I would favor having it automatically try some number of
>>>> servers or all, but not retrying at all would not be my choice.
>>>>
>>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
>>>> wrote:
>>>>
>>>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>>>
>>>>>> I would have to go looking, but the key concept is that this is a
>>> bigger
>>>>>> problem.
>>>>>>
>>>>>> interval such as the time between retries....
>>>>>> wait as in how long to wait for a response...
>>>>>>
>>>>>
>>>>> All time intervals should be expressed in terms of std::chrono::duration
>>>>> values. A value of std::chrono::duration::zero means don't wait. I would
>>>>> suggest that a negative time not be allowed and that some very large,
>>>>> MAXINT, value could take the place of "forever". There is a ticket
>>> already
>>>>> open and in progress to replace all time based values with std::chrono.
>>>>>
>>>>>
>>>>>> retry as how many times to retry after a failure
>>>>>> attempts as in how many times to do a thing before giving up
>>>>>> Set of objects as in the setRetryAttempts code which , will try a
>>>>> number of
>>>>>> servers before giving up. where n is the number, -1 equals all, and 0
>>>>> means
>>>>>> (1 server, no retries).
>>>>>>
>>>>>
>>>>> If there are other examples of "iteration" then we should consider them
>>>>> based on what they iterate. I think the consensus on setRetryAttempts is
>>>>> to
>>>>> abolish it.
>>>>>
>>>>> -Jake
>>>>>
>>>>
>>>>
>>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Mark Hanson <mh...@pivotal.io>.
The only problem with that is the time to connect to another server is non-deterministic. So, the code one would have to write to enable this would involve a select and a bit of not fun code, but in general could be not very useful as an API.
I would say the lowest common denominator approach or the server based approach is better.
Just two cents.
Thanks,
Mark
> On Aug 31, 2017, at 1:41 PM, Jacob Barrett <jb...@pivotal.io> wrote:
>
> I believe what Bruce was saying is that the behavior should be covered by
> timeouts not iteration attempts. If the client is able to successfully send
> the command to a server but a failure occurs waiting for a reply we would
> not retry. If the client is unable to send the request to a sever because
> the connection closes then we would try the next server, and the next, up
> to the timeout value.
>
> On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
>
>> I can also see why the user doing the retries themselves has value. As a
>> lowest common denominator approach, pulling the API is sound.
>>
>> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>>
>>> I think the setRetryAttempts really harks back to the case that Bruce was
>>> alluding to in which the server goes down. Which is the one valid case
>> for
>>> this kind of API in theory. Are we say that in that case we don't retry?
>>> Seems like we are making the API a little less nice for people.
>>> As a developer using an API, I want to do as little as possible and get
>>> the most robust solution possible. This seems to go the wrong direction
>> of
>>> that kind of intent in a way. I want the client to automatically try
>> every
>>> server. I don't ever want to configure the value. I could limit with this
>>> API and force it to never retry or I could cause it to retry more times
>>> than I care for it to. If we are going to get rid of this API in
>>> particular, I would favor having it automatically try some number of
>>> servers or all, but not retrying at all would not be my choice.
>>>
>>> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
>>> wrote:
>>>
>>>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>>>
>>>>> I would have to go looking, but the key concept is that this is a
>> bigger
>>>>> problem.
>>>>>
>>>>> interval such as the time between retries....
>>>>> wait as in how long to wait for a response...
>>>>>
>>>>
>>>> All time intervals should be expressed in terms of std::chrono::duration
>>>> values. A value of std::chrono::duration::zero means don't wait. I would
>>>> suggest that a negative time not be allowed and that some very large,
>>>> MAXINT, value could take the place of "forever". There is a ticket
>> already
>>>> open and in progress to replace all time based values with std::chrono.
>>>>
>>>>
>>>>> retry as how many times to retry after a failure
>>>>> attempts as in how many times to do a thing before giving up
>>>>> Set of objects as in the setRetryAttempts code which , will try a
>>>> number of
>>>>> servers before giving up. where n is the number, -1 equals all, and 0
>>>> means
>>>>> (1 server, no retries).
>>>>>
>>>>
>>>> If there are other examples of "iteration" then we should consider them
>>>> based on what they iterate. I think the consensus on setRetryAttempts is
>>>> to
>>>> abolish it.
>>>>
>>>> -Jake
>>>>
>>>
>>>
>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
I believe what Bruce was saying is that the behavior should be covered by
timeouts not iteration attempts. If the client is able to successfully send
the command to a server but a failure occurs waiting for a reply we would
not retry. If the client is unable to send the request to a sever because
the connection closes then we would try the next server, and the next, up
to the timeout value.
On Thu, Aug 31, 2017 at 1:31 PM Mark Hanson <mh...@pivotal.io> wrote:
> I can also see why the user doing the retries themselves has value. As a
> lowest common denominator approach, pulling the API is sound.
>
> On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
>
> > I think the setRetryAttempts really harks back to the case that Bruce was
> > alluding to in which the server goes down. Which is the one valid case
> for
> > this kind of API in theory. Are we say that in that case we don't retry?
> > Seems like we are making the API a little less nice for people.
> > As a developer using an API, I want to do as little as possible and get
> > the most robust solution possible. This seems to go the wrong direction
> of
> > that kind of intent in a way. I want the client to automatically try
> every
> > server. I don't ever want to configure the value. I could limit with this
> > API and force it to never retry or I could cause it to retry more times
> > than I care for it to. If we are going to get rid of this API in
> > particular, I would favor having it automatically try some number of
> > servers or all, but not retrying at all would not be my choice.
> >
> > On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
> > wrote:
> >
> >> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
> >>
> >> > I would have to go looking, but the key concept is that this is a
> bigger
> >> > problem.
> >> >
> >> > interval such as the time between retries....
> >> > wait as in how long to wait for a response...
> >> >
> >>
> >> All time intervals should be expressed in terms of std::chrono::duration
> >> values. A value of std::chrono::duration::zero means don't wait. I would
> >> suggest that a negative time not be allowed and that some very large,
> >> MAXINT, value could take the place of "forever". There is a ticket
> already
> >> open and in progress to replace all time based values with std::chrono.
> >>
> >>
> >> > retry as how many times to retry after a failure
> >> > attempts as in how many times to do a thing before giving up
> >> > Set of objects as in the setRetryAttempts code which , will try a
> >> number of
> >> > servers before giving up. where n is the number, -1 equals all, and 0
> >> means
> >> > (1 server, no retries).
> >> >
> >>
> >> If there are other examples of "iteration" then we should consider them
> >> based on what they iterate. I think the consensus on setRetryAttempts is
> >> to
> >> abolish it.
> >>
> >> -Jake
> >>
> >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
I can also see why the user doing the retries themselves has value. As a
lowest common denominator approach, pulling the API is sound.
On Thu, Aug 31, 2017 at 1:26 PM, Mark Hanson <mh...@pivotal.io> wrote:
> I think the setRetryAttempts really harks back to the case that Bruce was
> alluding to in which the server goes down. Which is the one valid case for
> this kind of API in theory. Are we say that in that case we don't retry?
> Seems like we are making the API a little less nice for people.
> As a developer using an API, I want to do as little as possible and get
> the most robust solution possible. This seems to go the wrong direction of
> that kind of intent in a way. I want the client to automatically try every
> server. I don't ever want to configure the value. I could limit with this
> API and force it to never retry or I could cause it to retry more times
> than I care for it to. If we are going to get rid of this API in
> particular, I would favor having it automatically try some number of
> servers or all, but not retrying at all would not be my choice.
>
> On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io>
> wrote:
>
>> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>>
>> > I would have to go looking, but the key concept is that this is a bigger
>> > problem.
>> >
>> > interval such as the time between retries....
>> > wait as in how long to wait for a response...
>> >
>>
>> All time intervals should be expressed in terms of std::chrono::duration
>> values. A value of std::chrono::duration::zero means don't wait. I would
>> suggest that a negative time not be allowed and that some very large,
>> MAXINT, value could take the place of "forever". There is a ticket already
>> open and in progress to replace all time based values with std::chrono.
>>
>>
>> > retry as how many times to retry after a failure
>> > attempts as in how many times to do a thing before giving up
>> > Set of objects as in the setRetryAttempts code which , will try a
>> number of
>> > servers before giving up. where n is the number, -1 equals all, and 0
>> means
>> > (1 server, no retries).
>> >
>>
>> If there are other examples of "iteration" then we should consider them
>> based on what they iterate. I think the consensus on setRetryAttempts is
>> to
>> abolish it.
>>
>> -Jake
>>
>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
I think the setRetryAttempts really harks back to the case that Bruce was
alluding to in which the server goes down. Which is the one valid case for
this kind of API in theory. Are we say that in that case we don't retry?
Seems like we are making the API a little less nice for people.
As a developer using an API, I want to do as little as possible and get the
most robust solution possible. This seems to go the wrong direction of that
kind of intent in a way. I want the client to automatically try every
server. I don't ever want to configure the value. I could limit with this
API and force it to never retry or I could cause it to retry more times
than I care for it to. If we are going to get rid of this API in
particular, I would favor having it automatically try some number of
servers or all, but not retrying at all would not be my choice.
On Thu, Aug 31, 2017 at 1:08 PM, Jacob Barrett <jb...@pivotal.io> wrote:
> On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
>
> > I would have to go looking, but the key concept is that this is a bigger
> > problem.
> >
> > interval such as the time between retries....
> > wait as in how long to wait for a response...
> >
>
> All time intervals should be expressed in terms of std::chrono::duration
> values. A value of std::chrono::duration::zero means don't wait. I would
> suggest that a negative time not be allowed and that some very large,
> MAXINT, value could take the place of "forever". There is a ticket already
> open and in progress to replace all time based values with std::chrono.
>
>
> > retry as how many times to retry after a failure
> > attempts as in how many times to do a thing before giving up
> > Set of objects as in the setRetryAttempts code which , will try a number
> of
> > servers before giving up. where n is the number, -1 equals all, and 0
> means
> > (1 server, no retries).
> >
>
> If there are other examples of "iteration" then we should consider them
> based on what they iterate. I think the consensus on setRetryAttempts is to
> abolish it.
>
> -Jake
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mh...@pivotal.io> wrote:
> I would have to go looking, but the key concept is that this is a bigger
> problem.
>
> interval such as the time between retries....
> wait as in how long to wait for a response...
>
All time intervals should be expressed in terms of std::chrono::duration
values. A value of std::chrono::duration::zero means don't wait. I would
suggest that a negative time not be allowed and that some very large,
MAXINT, value could take the place of "forever". There is a ticket already
open and in progress to replace all time based values with std::chrono.
> retry as how many times to retry after a failure
> attempts as in how many times to do a thing before giving up
> Set of objects as in the setRetryAttempts code which , will try a number of
> servers before giving up. where n is the number, -1 equals all, and 0 means
> (1 server, no retries).
>
If there are other examples of "iteration" then we should consider them
based on what they iterate. I think the consensus on setRetryAttempts is to
abolish it.
-Jake
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
I would have to go looking, but the key concept is that this is a bigger
problem.
interval such as the time between retries....
wait as in how long to wait for a response...
retry as how many times to retry after a failure
attempts as in how many times to do a thing before giving up
Set of objects as in the setRetryAttempts code which , will try a number of
servers before giving up. where n is the number, -1 equals all, and 0 means
(1 server, no retries).
On Thu, Aug 31, 2017 at 11:17 AM, Jacob Barrett <jb...@pivotal.io> wrote:
> Mark,
>
> Can you give concrete examples in the API?
>
> On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson <mh...@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 <jb...@pivotal.io>
> > wrote:
> >
> > > I should have scoped it to the native API.
> > >
> > > > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <
> bschuchardt@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 <mh...@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 <
> > ukohlmeyer@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 <
> > > bschuchardt@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 <
> > > prhomberg@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 <
> > mhanson@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
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >
> > >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
Mark,
Can you give concrete examples in the API?
On Thu, Aug 31, 2017 at 11:11 AM Mark Hanson <mh...@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 <jb...@pivotal.io>
> wrote:
>
> > I should have scoped it to the native API.
> >
> > > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <bschuchardt@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 <mh...@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 <
> ukohlmeyer@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 <
> > bschuchardt@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 <
> > prhomberg@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 <
> mhanson@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
> > >>>>>>>>>
> > >>>>>>>>>
> > >
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
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 <jb...@pivotal.io> wrote:
> I should have scoped it to the native API.
>
> > On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <bs...@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 <mh...@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 <uk...@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 <
> bschuchardt@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 <
> prhomberg@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 <mh...@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
> >>>>>>>>>
> >>>>>>>>>
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
I should have scoped it to the native API.
> On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt <bs...@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 <mh...@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 <uk...@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 <bschuchardt@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 <prhomberg@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 <mh...@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
>>>>>>>>>
>>>>>>>>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <mh...@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 <uk...@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 <bschuchardt@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 <prhomberg@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 <mh...@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
>>>>>>>>
>>>>>>>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <mh...@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 <uk...@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 <bschuchardt@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 <prhomberg@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 <mh...@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
>>>>>>>
>>>>>>>
>>>>>>>
>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Mark Hanson <mh...@pivotal.io>.
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 <uk...@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 <bschuchardt@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 <prhomberg@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 <mh...@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
>>>>>>
>>>>>>
>>>>>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Udo Kohlmeyer <uk...@pivotal.io>.
+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 <bs...@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 <pr...@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 <mh...@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
>>>>>
>>>>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Dan Smith <ds...@pivotal.io>.
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 <bs...@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 <pr...@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 <mh...@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
>>>>
>>>>
>
Re: [Discuss] Use of -1 as Infinite/All for retry related
functions...
Posted by Bruce Schuchardt <bs...@pivotal.io>.
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 <pr...@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 <mh...@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
>>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Jacob Barrett <jb...@pivotal.io>.
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 <ds...@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 <pr...@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 <mh...@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
>>>
>>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Dan Smith <ds...@pivotal.io>.
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 <pr...@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 <mh...@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
> >
>
Re: [Discuss] Use of -1 as Infinite/All for retry related functions...
Posted by Patrick Rhomberg <pr...@pivotal.io>.
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 <mh...@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
>