[jira] [Updated] (STORM-110) Add metrics for disruptor queue population

["Rick Kellogg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/STORM-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Kellogg updated STORM-110:
-------------------------------
    Component/s: storm-core

> Add metrics for disruptor queue population
> ------------------------------------------
>
>                 Key: STORM-110
>                 URL: https://issues.apache.org/jira/browse/STORM-110
>             Project: Apache Storm
>          Issue Type: New Feature
>          Components: storm-core
>            Reporter: James Xu
>
> https://github.com/nathanmarz/storm/issues/613
> @arrawatia has a first stab at a metrics producer for the disruptor queues: read head position, write head position and size, allowing a consumer to in turn calculate %full and throughput. Currently it's an IMetric that reports the numbers directly whenever getValueAndReset() is called.
> Would you like to add this to the builtin metrics in core? It's useful for determining if the buffer capacities needs tuning -- and it's otherwise really difficult to get figures on it without flooding the logs.
> * Should this be done with the stats framework, the metrics framework, or both?
> * One metric per disruptor queue, or one combined hash per worker? I prefer one-per-queue, but we had trouble finding the right place to instantiate the metric: the metric needs a handle on the disruptor queue and needs to know what executor it will belong to. So right now the spike implementation lives with the system metrics.
> * Is direct response to getValueAndReset() the right approach, or should this be a MeanReduced metric?
> ----------
> nathanmarz: This will be an awesome feature addition and should be done with the metrics framework. There should be one metric per queue.
> I'm not entirely sure on the right way to implement this, but it's critical to a) not introduce any race conditions, and b) have minimal impact on performance. I look forward to seeing a pull request for this and let me know if you have any questions regarding semantics.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)