On Tue, Mar 30, 2021 at 02:54:55PM +0200, Willy Tarreau wrote:
> And I've tested using the same method (http_req_rate(2s) and 500ms this
> time to cover both >1s and <1s). So I don't know what to say. I'm now
> extremely tempted to revert all these fixes because in the end the
> original problem was much less visible for most users :-(
>
> I'm now trying with this *exact* config in case I missed something else.
So I was not crazy. The reason is that... the date changed since my
tests one week ago :-(
The new date is updated if it's in the past compared to the newest one,
except that it starts at zero. Last week during my tests, the now_ms
date was ~1.6 billion. 0-1.6 billion is negative so the new_now_ms date
was updated to reflect it.
But today the date it ~2.2 billion, which is higher than 2^31, thus
0-2.2 billion is positive and the new date is not after the old one so
the old one is not updated.
Thus we need to special case the update to reflect this. What saddens
me is that I hesitated to completely rewrite this part to simplify it
and concluded that I'd rather stay on the safe side. Someone getting
rid of legacy would be better, really!
This patch fixes it.
Sander, Thomas, please check again with it, it MUST work this time!
Thanks,
Willy
diff --git a/src/time.c b/src/time.c
index 0cfc9bf3c..fafe3720e 100644
--- a/src/time.c
+++ b/src/time.c
@@ -268,7 +268,7 @@ void tv_update_date(int max_wait, int interrupted)
old_now_ms = global_now_ms;
do {
new_now_ms = old_now_ms;
- if (tick_is_lt(new_now_ms, now_ms))
+ if (tick_is_lt(new_now_ms, now_ms) || !new_now_ms)
new_now_ms = now_ms;
} while (!_HA_ATOMIC_CAS(&global_now_ms, &old_now_ms, new_now_ms));
