On Wed, Sep 6, 2017 at 4:37 PM Mark Hanson 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
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 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
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
Perfect!
> On Sep 6, 2017, at 3:13 PM, Jacob Barrett 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
> v
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
> On Sep 6, 2017, at 2:29 PM, Jacob Barrett 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
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
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
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
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 wrote:
> So the basic challenge here i
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 i
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
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
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 wrote:
>
> The only problem with that is the time to connect to another server is
> non-det
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
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
t
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 wrote:
> I think the setRetryAttempts really harks back to the case that Bruce was
> alluding to in which the server
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 develope
On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson 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::chr
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
Mark,
Can you give concrete examples in the API?
On Thu, Aug 31, 2017 at 11:11 AM 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:
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 c
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 obje
I should have scoped it to the native API.
> On Aug 31, 2017, at 10:30 AM, Bruce Schuchardt 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 a
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
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 wrote:
>
> As I underst
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 th
+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
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
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 re
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 wrote:
>
> In general, I think we need making the configu
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 ag
-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 retr
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
34 matches
Mail list logo
