Open ugo-fl opened 2 years ago
Hi @ugo-fl, thank you for raising the issue, we will try to reproduce it.
Since you mention @PreDestroy
, are you creating client instances for each web request? If so, having to call .stop()
is expected: the client starts background threads, so an explicit call is needed to stop them when the client instance is no longer needed. At the same time, creating and stopping a client instance is relatively expensive, so I would recommend to have only one global instance per application. The client is thread safe and the same instance can be used to send metric from all resources.
Hello @vickenty, thank you for your feedback.
I've just tried with a singletonized version of the client, now no metrics are being sent/received and the memory still goes up. When the whole API is a singleton then I get the metrics properly, but the memory leak is still present.
I think I'm going to quit using the client for the moment and try to post metrics directly instead.
Wait actually it went up in the first 20 minutes but now after a few hours it seems to have stabilized. I'll come back at you after some days, but to setup the API as a singleton could be the solution.
Has anyone observed such issues on version 4.2.0 of the statsD client?
Currently using this client (3.0.0) within a JAX-RS API and experiencing a memory leak which causes after a certain time the server to crash.
After adding a
@PreDestroy
method which callsstatsd.stop()
the curve is smoothed, but still going up :Without this, it only takes a few hours for our server to freeze.