Fork me on GitHub

I don’t think I announced this 3 months ago but we forked dogstatsd-clj here. It is a statsd client, with support for the datadog dogstatsd extensions; the non-datadog specific stuff should also work with other statsd systems, e.g. graphite… It makes a few improvements to the original; most notably not using a singleton client for the connection, which makes it much less opinionated and easier to use in component systems e.g. integrant, component etc. This required making a breaking change to the original library; hence it being a fork.

👀 6
🎉 2

nice work! we may end up switching to your version 😁 also, not sure if your update accounts for this or not, but it looks like we missed this Issue:


This dependency also works with #babashka btw :)

$ bb -cp $(clojure -Spath -Sdeps '{:deps {org.babashka/spec.alpha {:git/url "" :git/sha "1a841c4cc1d4f6dab7505a98ed2d532dd9d56b78"}}}'):test -e "(require '[swirrl.dogstatsd-test]) (clojure.test/run-tests 'swirrl.dogstatsd-test)"

Testing swirrl.dogstatsd-test

Ran 1 tests containing 1 assertions.
0 failures, 0 errors.
{:test 1, :pass 1, :fail 0, :error 0, :type :summary}
@U0JEFEZH6 is running a similar thing with bb on their nodes.


Yes I would have expected it probably would :thumbsup: I would mention it in the README, but as it stands there’s no CI setup here, and without CI testing it under bb it I’m not 100% comfortable making the claim that it will remain that way… though I don’t expect any major changes to the library anytime soon


I already made an issue about it on the bb side, we test a lot of libraries on bb's CI., If you're open to receiving a github actions config, I can setup both clj + bb tests.


You can introduce bb reader conditionals or just drop bb support at any time of course. We'll just fork the lib if necessary if people find it useful. But you can also use bb reader conditionals to support bb separately from clojure in case of incompatible changes.


I’m certainly open to seeing it; but I wouldn’t want to waste your valuable time, as we’re currently using circleci for some of our other builds, with some older stuff on travis (probably to be migrated at some point) — and I’d rather not have to introduce a 3rd CI into the mix. That said we have started using GH actions for some checks, so might not be that big a deal… I’d still like to keep the cognitive overhead down for everyone though


I'm also familiar and even a fan of CircleCI, that wouldn't be a dealbreaker to me. But it's ok, I'll just test it at the bb side and if things will break, then we'll just improve bb in the best way we can ;)


I’m not sure it’s a dealbreaker for me to be honest 🙂 Tell you what, if you are still happy to contribute the GHA — I’ll merge it and if/when we do move to circle, I’ll promise to also include bb support in the tests (and maintain it as best I can)🙂


sounds good

🙌 1
🙇 1

Oh nice, our statsd client implementation is very simple, but also supports only the bare minimum statsd protocol (so no DataDog extensions like tags etc).


please squash the commits into one (github has a squash/merge option)


Wow amazing, thank you so much! I’ll take a proper look at it on monday as I’m about to finish for the day 🙇


@U06HHF230 also, if it helps - our (other) Statsd client (which wraps DD's Java lib) runs a "real" UDP server so we can ensure all metrics are sent correctly over the wire, you can find it here:


@U0JEFEZH6 Thanks. I did consider doing something like that, it just didn’t feel worth it at the time — given that it had no tests prior to forking it. The main thing adding the tests was intended to catch was just dumb stuff like syntax errors and calling functions wrongly. So there are also some specs that test the inputs to format-metric are correct, which I think give a slightly bigger bang per buck than just asserting the string you sent can be received over UDP, though I’d certainly be happy to have a test for that and a few other things. Unfortunately most of the complexity and testing here is in making sure the metric events are interpreted as expected in your metrics system, and there’s not really a good automated way to do that; at least not one that feels worth the complexity cost.

alexmiller18:01:21 is now available • Fix deadlock in version range resolution • Fix race condition during parallel loading of s3 transporter • Don’t track local deps.edn manifest for caching if deps project doesn’t have one • Update maven-core to 3.8.4, aws libs,, to latest • Use 0.12.1109

🎉 22