Some doc on metrics and writing thread safe code

[Shaun Montgomery]

I'm new to Metrics and I'm trying to use Metrics Timers in a multi-threaded environment.  After reading other posts on this group, I'm looking for some doc on the best way to keep the threads from overwriting each other's data.  I'm a little confused as to "fully thread safe" and references to having a different timer name for each thread.  Can someone explain?

Thanks

[Ryan Rupp]

Everything should be thread safe, have you encountered any issues in particular with this or just wondering? Unfortunately I don't know if this is actually called out anywhere in the docs but the library is designed to be thread safe, there's an issue logged to actually document this - https://github.com/dropwizard/metrics/issues/890 - but if you look through some of the source code you can see things like ExponentiallyDecayingReservoir (which timers use by default) uses read/write locks to be thread safe - https://github.com/dropwizard/metrics/blob/master/metrics-core/src/main/java/io/dropwizard/metrics/ExponentiallyDecayingReservoir.java#L99

Then meters or anything with counts typically use LongAdder or AtomicLonger for thread safe updates.

So, in your case you would just give a reference to each Thread with the particular Timer you're interested in and update it and it should track all updates across multiple threads.

[Shaun Montgomery]

From what you've said, maybe I'm thinking of this the wrong way.  I'm in the design phase at this time.

My application will NOT need to start timers from one thread and stop them from another.

What I am trying to do is record the amount of time it takes to receive a response from a web service.  Multiple threads will be making calls to the same web service and I'd like to be able to combine the durations into one timer so I can see/combine the overall statistics.  The start and stop time for each thread would need to be independent.  Can I have each thread create its own context from the same timer?  The other option appears to be making different timers for each thread and then somehow combining the statistics in some sort of post processing but that seems to defeat the cool statistics from Metrics.

[Ryan W Tenney]

Yes, that's exactly what the library does by default.

--
You received this message because you are subscribed to the Google Groups "metrics-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to metrics-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Shaun Montgomery]

Thanks Ryan,

Based on what you said, I've set things up to allow each thread to use Timer.time to create its own context.  Returning this context allows each thread to then stop the Timer.Context when they are done.

--
You received this message because you are subscribed to a topic in the Google Groups "metrics-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/metrics-user/DgcB9qJEThI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to metrics-user...@googlegroups.com.