> That's what the sampling code does - it holds an AtomicLongArray of fixed > length, and updates the values in there randomly. There's also an > ExponentiallyDecayingSample which biases the collection of values towards > more recent entries, for the 5-minute and 15-minute window averages. You can > see the patch here:
Ah, ok! I just remembered that some of this stuff was exploding memory and Uwe reverted it so that Jenkins could do its job. Don't know if it was a bug or something else - had very little time to look into it. > TBH, I'm not even sure we need a ThreadLocal random here, though. Are there > likely to be thread-safety issues when generating random numbers? I think they may be using it to avoid synchronizations on the default Random implementation. I honestly don't think this is going to be a problem in practice if you replaced the ThreadLocal random with just a Random (even if there are conflicts adding random + random noise = random noise). If the rate of updates is really high, or if you want a better random generator than the default (which you may want to consider) then copy a random generator from commons math and voila, should be fine? Dawid --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
