Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Inlined my thought, but totally agreed with Bobby. Starting with good questions seems more important than trying to measure more parts. Thanks for bring up your opinion. Thanks, Jungtaek Lim (HeartSaVioR) 2016년 5월 23일 (월) 오후 10:36, Bobby Evans 님이 작성: > From JStorm we got

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Taking queue depth is a good idea for measuring load of components though there're some scenarios that users want to know the latency of a specific method/processing flow. BTW., we've added support to turn on/off metrics dynamically in JStorm(actually we had this feature in JStorm 2.1.1 but

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

I am working on adding queue depth metrics. https://github.com/apache/storm/pull/1406 On Mon, May 23, 2016 at 7:21 PM, Cody Innowhere wrote: > Taking queue depth is a good idea for measuring load of components though > there're some scenarios that users want to know the

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Taking queue depth is a good idea for measuring load of components though there're some scenarios that users want to know the latency of a specific method/processing flow. BTW., we've added support to turn on/off metrics dynamically in JStorm(actually we had this feature in JStorm 2.1.1 but

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

>From JStorm we got the ability to show most of the metrics on the UI, but I >think we missed the ability to turn on and off metrics dynamically.  This is >important because there will be metrics that are expensive to gather, but very >important when debugging specific problems. I also think we

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Thanks for following up, Abhishek. I agree with you about the consensus. I think you already listed most of my / community requirements. I'm adding up something I have in mind, 7. Aggregation at stream level (STORM-1719 ), and machine level 8.

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

So I am assuming that there is a general consensus on adding new api for metrics and gradually phasing out the old one. If yes, may be we can work toward finer details of how to maintain two apis as well as the design of new API. Jungtaek, it would be better to summarize the requirements and let

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Personally I'm also in favor of maintaining old API (but deprecated) and adding new API. It's ideal way, and that's what many projects are trying to do, and so on the other project I'm also maintaining. And I also prefer to gone away current metrics feature in next major release. In general,

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

Sounds good. Having two separate metric reporters may be confusing but it is better than breaking the client code. Codahale library allows user to specify frequency per reporter instance. Storm on the other hand allows different reporting frequency for each metric. How will that mapping work? I

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

I personally would like to see that change happen differently for the two branches. On 1.x we add in a new API for both reporting metrics and collecting in parallel to the old API.  We leave IMetric and IMetricsConsumer in place but deprecated.  As we move internal metrics over from the old

Re: [DISCUSSION] opinions on breaking changes on metrics for 1.x

If we want to refactor the metrics system, I think we may have to incur breaking changes. We can make it backward compatible but this means we may build an adapt layer on top of metrics, or a lot of "if...else..." which might be ugly, either way, it might be a pain to maintain the code. So I