indeedeng / java-dogstatsd-client Goto Github PK

I'm using this library and I need to report runtimes to datadog. The readme claims that passing in long timeInMs will get converted to fractional seconds. From using the library and reading the source, it looks like this is not the case (this is however the case in the tim-group repo https://github.com/tim-group/java-statsd-client). If this could be fixed that would be ideal, but for the time being the specification in the readme should be updated. Thank You.

My use case:

Instant start = Instant.now();
... operations ...
Main.statsD.time("runtime", Duration.between(start, Instant.now()).toMillis());

My datadog graph shows runtime in the range of 13 seconds, but this operation is used in a web environment and server response is ~25 ms. Thus, 13 ms makes much more sense.

I want to count the records I've written to Kinesis successfully and unsuccessfully, but I write them as batches, so I send the request, then I'm told that x succeeded and y failed. Usually, x = 20 and y = 0.

Right now I have this Scala code:

    val resp = kinesis.putRecords(req)

    // count successful and failed records
    for (ix <- 0 until resp.getFailedRecordCount())
      datadog.increment("kinesis.record-fail")
    for (ix <- resp.getFailedRecordCount() until events.size)
      datadog.increment("kinesis.record-written")

It would obviously be much more efficient to be able to write it like so:

    val resp = kinesis.putRecords(req)

    // count successful and failed records
    datadog.increment("kinesis.record-fail", resp.getFailedRecordCount())
    datadog.increment("kinesis.record-written", (events.size - resp.getFailedRecordCount())

This is not just shorter, but it also means less Datadog traffic and fewer events for the Datadog agent to process, and so on. For a service that's under high load this actually makes a difference.

The class NonBlockingStatsDClient is not thread-safe (and presumably it should be). The reason for this is that a static NumberFormat instance is shared among all threads, but this class itself is not thread-safe. See the "synchronization" section of the NumberFormat docs:

http://docs.oracle.com/javase/6/docs/api/java/text/NumberFormat.html

To fix this problem, either create a new NumberFormat for each call, or create one per thread, using a ThreadLocal<NumberFormat>

http://stackoverflow.com/questions/1285279/java-synchronization-issue-with-numberformat

Hello!

Looks like there are some pending changes in master, specifically the switch from int to long that didn't get released. Can we get a new release of 2.0.9? I'd love to use it for an issue I'm working on for metrics-datadog.

Thanks!

Any chance you guys can do a new release? It looks like you may have some fixes in master for something I'm seeing:

tsd[6437]: ERROR (dogstatsd.py:311): Error receiving datagram
Traceback (most recent call last):
File "/opt/datadog-agent/agent/dogstatsd.py", line 299, in start
aggregator_submit(message)
File "/opt/datadog-agent/agent/aggregator.py", line 604, in submit_packets
parsed_packets = self.parse_metric_packet(packet)
File "/opt/datadog-agent/agent/aggregator.py", line 479, in parse_metric_packet
raise Exception('Metric value must be a number: %s, %s' % (name, raw_value))
Exception: Metric value must be a number: responses.inbound.nobid.mean, �

I think the Aug 7th commit for NaN would fix this, but we just need a new release out!

Looking at the StatsDClient class, I see that there is a recordEvent() method which accepts an Event as a parameter. However, the documentation has no usage examples for this, only for metrics. I've been doing it like this, but the data doesn't seem to be coming through:

StatsDClient statsd = new NonBlockingStatsDClient( /* some parameters */ );
Event event = Event.builder().withTitle("title").withText("body").build();
statsd.recordEvent(event);

Right now, conversion from double to string executed by NonBlockingStatsDClient.FORMAT depends on the locale of the user. If the user's locale is one where a comma is used as a decimal point, the Datadog Agent will not be able to parse a metric with a double value.

This library is effectively repackaging the library it was forked from. This causes classpath loading issues.

If you have a library that depends on the forked library and another one which depends on this, you end up with two classes with the same name with possibly different binary interfaces (e.g. in the count method on NonBlockingStatsDClient).

Please never ever do something foolish as this. Just properly rename that package.

It would be much easier to create tests mocks manually if this were not final, and what's the benefit of making it final, anyway? I'll be happy to make a pull request for this if it's likely to be accepted.

As per the title, one has to dig through the source to derive whether or not the lib is thread-safe.

Even if the lib is not intended to guarantee thread-safety, it would be great to have a note specifying that.

Thanks!