tiedotguy
tiedotguy
I dealt with this with a wrapper which periodically checks the modification / hash (and a `sync.RWMutex`, as you say, @inliquid) https://gist.github.com/tiedotguy/b8a29519c4690b45f89c003a37e36402 It's a bit more complicated in reality 'cause...
I believe the `-80` in `BenchmarkReceive-80` is the number of cores, but I suspect it's really only got 2, so we're probably thrashing it.
Hi I believe this approach is an anti-pattern. When running in a sidecar configuration like this (which is generally how we run it as well these days), the provider isn't...
Hi I've done a bunch of thinking about this, because I don't like this solution, but I recognize it's a pain to add additional tooling to an instance to lookup...
Disregard coveralls, it's confused because of the refactoring.
No worries mate, appreciate all the work you put in to it!
I mean... so does etsy statsd, but here we are with gostatsd :)
There's a bunch of logic copied from there in to MetricMap.Merge, it should be cleaned up as well.
Once again we need to ignore coveralls, I think it's just sad because there's new code without sufficient coverage to actively increase the %.
Oh hey I never got this merged. I'll clean it up later.