Question #186672 on Graphite changed: https://answers.launchpad.net/graphite/+question/186672
Michael Leinartas proposed the following answer: Sidnei's correct - since that check happens only at the beginning of optimalWriteOrder before it enters the loop which pops off metrics from the cache, the unpause is only triggered once the cache is drained completely. I committed a fix in r673 that was tested by the original poster (thanks Drew). I chose to do the check at every loop - I feel it's not going to be impactful to check it each time since it's first doing a simple true/false check (state.cacheTooFull). In the case of a paused receiver, it does an integer compare. If that were to be at all impactful, it should be the same impact as the compare required to check it every N times. The key here is that MetricCache accounts for it's size in the 'size' attribute on every store() and pop(). If it were calculating the size each time that attribute was accessed it'd certainly be a concern. As far as the MAX_CREATES_PER_MINUTE, I noticed that as well when reading through this and found the behavior surprising as well. I think I'm going to open a bug to discuss it - at the very least, this behavior needs to be clearly documented in the sample config file. -- You received this question notification because you are a member of graphite-dev, which is an answer contact for Graphite. _______________________________________________ Mailing list: https://launchpad.net/~graphite-dev Post to : graphite-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~graphite-dev More help : https://help.launchpad.net/ListHelp
