- User Since
- Jan 13 2015, 10:58 PM (192 w, 3 d)
Thu, Sep 20
Wed, Sep 19
Mon, Sep 17
Mon, Aug 27
Fri, Aug 24
Aug 23 2018
Aug 22 2018
Aug 21 2018
Aug 18 2018
Aug 17 2018
Aug 9 2018
Aug 8 2018
Aug 7 2018
Aug 5 2018
Aug 2 2018
Aug 1 2018
Jul 31 2018
Jul 30 2018
Jul 29 2018
Jul 28 2018
Jul 27 2018
Jul 21 2018
Jul 20 2018
I just ran a test without the timeout in the loop waiting for a connection
attempt and the time it took for a failover was only 1minute more than
with that patch.
Jul 19 2018
The problem is that, without the "timeout" it takes too long for the msleep() to wake up.
The "timeout" or whatever you prefer to call it is meant to set the upper bound on the
time that this loop waits for a TCP connection to complete to approximately
tv.tv_sec (the same timeout as set for SO_SNDTIMEO).
Added comments as kib@ suggested and used tvtohz(), so that tv_usec component is included in timeout.
(I have emailed kib@ one that uses the 1sec timeout and I put that here if he prefers that one.)
I commented inline. I'll admit I don't see spurious wakeup()s will be a problem.
I can (actually already have for the patch I have) include the tv_usec field in
the timeout calculation.
(I'll admit I get nervous fooling with things like time_uptime, which can go
negative in 2038 and assorted things related to overflow.)
Jul 18 2018
Explained inline, but basically timeouts at both places count as one retry
and the RPC attempt fails when the limit on these retries is reached,
so it seems to me that they should be the same amount of time?
Jul 17 2018
I added an inline comment which was basically that I didn't think a timeout of a fraction
of 1sec or setting a timeout of greater than 1sec resolution would be useful.
(My assumption is that normal operation against a slow server could result
in delays of 1sec.)