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, before each major release we should discuss which classes/features to drop. I think we forgot this when we release 1.0.0, and deprecated things are all alive. I'm also in favor of dropping the support for custom frequency for each metric. I guess we don't need to worry about mapping since internal metrics on Storm will be moved to new metrics feature. While some behavioral changes could be occurred (for example, IMetricsConsumer could be changed to no longer receive built-in metrics on Storm), it will not break backward compatibility from the API side anyway. Thanks, Jungtaek Lim (HeartSaVioR) 2016년 5월 20일 (금) 오전 12:57, Abhishek Agarwal <abhishc...@gmail.com>님이 작성: > 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 am ok to drop the support for custom > frequency for each metric. Internal metrics in storm anyway use same > frequency of reporting. > > On Thu, May 19, 2016 at 9:04 PM, Bobby Evans <ev...@yahoo-inc.com.invalid> > wrote: > > > 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 interface > to > > the new one, we either keep versions of the old ones in place or we > provide > > a translation shim going from the new to the old. > > > > In 2.x either the old way is gone completely or it is off by default. I > > prefer gone completely. > > > > If we go off of dropwizard/codahale metrics or a layer around them like > > was discussed previously it seems fairly straight forward to take some of > > our current metrics that all trigger at the same interval and setup a > > reporter that can translate them into the format that was reported > > previously. > > In 1.x to get a full picture of what is happening if your topology you > may > > need two separate reporters. One for the new metrics and one for the > old, > > but it should only be for a short period of time. - Bobby > > > > On Thursday, May 19, 2016 1:00 AM, Cody Innowhere < > e.neve...@gmail.com> > > wrote: > > > > > > 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 prefer to making breaking changes if we want to build a new metrics > > system, and I'm OK to move JStorm metrics migration phase forward to 1.x, > > and I'm happy to share our design & experiences. > > > > On Thu, May 19, 2016 at 11:12 AM, Jungtaek Lim <kabh...@gmail.com> > wrote: > > > > > Hi devs, > > > > > > I'd like to see our opinions on breaking changes on metrics for 1.x. > > > > > > Some backgrounds here: > > > > > > - As you may have seen, I'm trying to address some places to improve > > > metrics without breaking backward compatibility, but it's limited due > to > > > interface IMetric which is opened to public. > > > - We're working on Storm 2.0.0, and evaluation / adoption for metrics > > > feature of JStorm is planned to phase 2 but we all don't know estimated > > > release date, and I feel it's not near future. > > > - We've just released Storm 1.0.x, so I expected the lifetime of Storm > > 1.0 > > > (even 0.9) months or even years. > > > > > > If someone wants to know what exactly things current metrics feature > > > matter, please let me know so that I will summarize. > > > > > > I have other ideas on mind to relieve some problems with current > metrics, > > > so I'm also OK to postpone renewal of metrics to 2.0.0 with applying > > those > > > workaround ideas. But if we're having willingness to address metrics on > > > 1.x, IMO we can consider breaking backward compatibility from 1.x for > > once. > > > > > > What do you think? > > > > > > Thanks, > > > Jungtaek Lim (HeartSaVioR) > > > > > > > > > > > > > > > -- > Regards, > Abhishek Agarwal >
