logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45753] Code contribution: BurstFilter for extras
Date Mon, 03 Oct 2011 17:53:02 GMT

--- Comment #12 from John Vasileff <git@netcc.us> 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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message