bneradt commented on PR #13816: URL: https://github.com/apache/trafficserver/pull/13816#issuecomment-6064725911
Thanks for the thorough review and the reproduction. I've pushed an update addressing all four points. **Blocking: `has_debt()` clock read.** I went with your first option: `has_debt()` now passes `timestamp` through, so each bucket reads the clock only after loading its own state, and there's a comment in `tokens()` explaining why that order matters. I didn't take the signed-elapsed option because it would treat a bucket idle for more than about 24.8 days (2^31 ms) as having zero elapsed time. A read would then report debt that was long since repaid, and `consume()` would lose the full replenishment it gets today. The cost is one `steady_clock` read per bucket, which only adds up when `contest()` probes many slots. I added a threaded regression test with one thread consuming on a bucket deep in debt while another loops on `is_evictable()`. Against the hoisted read it fails consistently (32 to 42 "evictable" reads per 2M checks); with the fix it is 0. **Limits comment.** Agreed. The comment now says a reader can pair the state with the previous rate after a reload, that this can over- or under-replenish by a bounded amount, and that the next consume corrects it. Burst is no longer part of the argument. **Wall-clock races in older tests.** The `TokenBucket` and `RuleBuckets` tests now pin timestamps. `TxnData::consume()` doesn't take a timestamp, so the tracker test now checks that the balance is between 9 and the burst of 10. The table-eviction test now builds up about 1,000 seconds of debt at rate 1, so a stalled host can't repay it during the test. **Block-expiry AuTest.** Step 4 now records `abuse_shield.actions.blocked`, sends two requests, and checks that both get a 200 and the metric doesn't change. With the previous `ip_data` it fails with `second=000 blocked_delta=1`: the stale debt re-blocks the IP on the first request, so the second is rejected. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
