Query size of single thread executor in NonBlockingStatsDClient

[Jens Rantil]

For a lot of metrics, it's is crucial to also monitor the size of the queue in the executor in NonBlockingStatsDClient. I propose opening up to supply a custom executor to the constructor. I think that's the most flexible solution. That said, is NonBlockingStatsDClient#clientSocket(...) thread safe?

[Tom Denley]

Ultimately, this depends on http://docs.oracle.com/javase/7/docs/api/java/net/DatagramSocket.html#send(java.net.DatagramPacket) being thread safe, which, as far as I can ascertain, it is.

I'll have a look at introducing some more flexibility around the Executor in a forthcoming release, but I'm working on the other bugs and feature requests first.

In the meantime, I'd be interested in the techniques you employ to monitor the size of an executor queue.

[Jens Rantil]

Currently not using statsd-client in production, but we do monitor BlockingQueue size of Executors. The way we do this is by manually instantiating and supplying a BlockingQueue to our Executor implementation. We then periodically poll the size of the queue. This obviously does not monitor the number of running threads (that have been polled off the queue), which is another thing we monitor separately.

[Tom Denley]

Thanks for the information -- it seems likely that I could change the statsd-client to take ownership of its own work queue in the way you describe, and to provide a way of monitoring the length of that queue. As, in the current implementation, there is only ever one running thread, monitoring that would not be necessary.

I'm going to think more on this before making any changes.

[Jens Rantil]

👍

[Krishna]

Do you expect us to write threadlocal implementations to return the same StatsDClient per thread, remove() after request is processed or it is already done internally?

How do we monitor the BlockingQueue size? Why is it called NonBlocking then?