https://issues.apache.org/bugzilla/show_bug.cgi?id=45753
--- Comment #12 from John Vasileff <[email protected]> 2011-10-03 17:53:02 UTC --- I took a look at BurstFilter and have a few thoughts: 1) The calculation of burstInterval loses precision. Better may be to store burstIntervalNanos with something like: this.burstIntervalNanos = NANOS_IN_SECONDS * max / rate; Currently with rate=16 and maxBurst=100, the burstInterval becomes 6L seconds instead of 6.25F seconds, so the effective rate is 100F/6 == 16.667. A much worse scenario exists when bursting is disabled. For example, rate=2 and maxBurst=1, the effective rate is infinite (burstInterval = 1/2 == 0). More generally, burstInterval becomes 0 when rate > maxBurst. 2) It may be valuable to define rate as a float to allow fractional rates. One example is a job processor that logs trace("pending jobs: " + queue.size()) whenever a job is processed. The deployer may want to monitor load throughout the day, but no more frequently than once every 100s. This could be accomplished with rate=0.01, max=1. 3) It probably makes sense to restrict max to between 1 and 1k or something to avoid overflow errors and unnecessary memory/processing overhead. And of course if burstIntervalNanos <= 0, filtering can be disabled. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
