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)
>
