I think it is totally fine to add a "ThreadsafeCounter" that uses an atomic long internally
On Sat, Jun 11, 2016 at 7:25 PM, Steve Cosenza <scose...@twitter.com> wrote: > Also, we may be able to avoid the need for concurrent metrics by > configuring each Finagle source to use a single thread. We'll investigate > the performance implications this week and update you with the results. > > Thanks, > Steve > > > On Friday, June 10, 2016, Steve Cosenza <scose...@twitter.com> wrote: > >> +Chris Hogue who is also working on operationalizing Flink with me >> >> Hi Stephan, >> >> Thanks for the background on your current implementations! >> >> While we don't require a specific implementation for histogram, counter, >> or gauge, it just became clear that we'll need threadsafe versions of all >> three of these metrics. This is because our messaging source is implemented >> using Finagle, and Finagle expects to be able to emit stats concurrently >> from its managed threads. >> >> That being said, if adding threadsafe versions of the Flink counters is >> not an option, we'd also be fine with directly reading and writing from the >> singleton Codahale MetricsRegistry that you start up in each TaskManager. >> >> Thanks, >> Steve >> >> On Fri, Jun 10, 2016 at 7:10 AM, Stephan Ewen <se...@apache.org> wrote: >> >>> A recent discussion brought up the point of adding a "histogram" metric >>> type to Flink. This open thread is to gather some more of the requirements >>> for that metric. >>> >>> The most important question is whether users need Flink to offer >>> specific implementations of "Histogram", like for example the " >>> com.codahale.metrics.Histogram", or if a " >>> org.apache.flink.metrics.Histogram" interface would work as well. >>> The histogram could still be reported for example via dropwizard >>> reporters. >>> >>> *Option (1):* If a Flink Histogram works as well, it would be simple to >>> add one. The dropwizard reporter would need to wrap the Flink Histogram for >>> reporting. >>> >>> *Option (2)*: If the code needs the specific Dropwizard Histogram type, >>> then one would need a wrapper class that makes a Flink Histogram look like >>> a dropwizard histogram. >>> >>> ---------- >>> >>> As a bit of background for the discussion, here are some thoughts behind >>> the way that Metrics are currently implemented in Flink. >>> >>> - The metric types in Flink are independent from libraries like >>> "dropwizard" to reduce dependencies and retain freedom to swap >>> implementations. >>> >>> - Metric reporting allows to reuse reporters from dropwizard >>> >>> - Some Flink metric implementations are also more lightweight than for >>> example in dropwizard. Counters for example are not thread safe, but do not >>> impose memory barriers. That is important for metrics deep in the streaming >>> runtime. >>> >>> >>> >> > > -- > -Steve > > Sent from Gmail Mobile >
