+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 <mhan...@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 <jbarr...@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 <mhan...@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 <jbarr...@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 <mhan...@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 <mhan...@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 <jbarr...@pivotal.io>
wrote:
On Thu, Aug 31, 2017 at 1:00 PM Mark Hanson <mhan...@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
