Please sign in to comment.
ClientConnect retries should compare with actual elapsed time
Summary: "retries" is supposed to roughly represend the number of seconds hh_client will reattempt connections to a broken/busy/missing server. In many scenarios, it doesn't do this at all. For example, consider SMUtils.Monitor_socket_not_ready, which will most commonly be triggered with "hh_server -d my_repo && hh_client my_repo" Since daemonizing finishes very quickly (and many hundreds of milliseconds before the actual daemonized server starts listening on the socket), the hh_client will get Monitor_socket_not_ready as long as the Monitor is running but hasn't yet started listening in on the socket. In this case, ClientConnect will retry "connect" immediately and rapidly consume all "retries" within milliseconds and fail instead of retrying for up to #"retries" seconds. This fixes that. We switch to using real elapsed time so "retries" really resembles number of seconds we will retry for. Add a short "sleepf 0.1" between some retries so we don't peg the CPU at 100%. (note: a number of the recursive retries already have a time delay built in, such as with "Unix.select" so don't need a sleep). Reviewed By: ljw1004 Differential Revision: D6983696
- Loading branch information...
Showing with 10 additions and 6 deletions.