Hadoop Common
  1. Hadoop Common
  2. HADOOP-7734

metrics2 class names inconsistent between trunk and 20x

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Critical Critical
    • Resolution: Unresolved
    • Affects Version/s: 0.20.205.0, 0.23.0
    • Fix Version/s: None
    • Component/s: metrics
    • Labels:
      None

      Description

      The new metrics2 framework was backported into the 20x branch, but the class names differ between the two branches. So, if anyone were to build against the metrics2 API in 20x, it would break when they upgraded to 23. We should reconcile the two so that they are API-compatible.

        Issue Links

          Activity

          Hide
          Luke Lu added a comment -

          It's possible but this involves evolving metrics2.1 a bit more to avoid name conflicts. It's gonna be quite ugly though.

          Show
          Luke Lu added a comment - It's possible but this involves evolving metrics2.1 a bit more to avoid name conflicts. It's gonna be quite ugly though.
          Hide
          Todd Lipcon added a comment -

          Is it possible to backport "metrics2.1" in such a way that "metrics2.0" isn't broken in the process? I don't know the APIs well enough.

          Show
          Todd Lipcon added a comment - Is it possible to backport "metrics2.1" in such a way that "metrics2.0" isn't broken in the process? I don't know the APIs well enough.
          Hide
          Luke Lu added a comment -

          HBase is stuck using metrics1 until all of our users move to 0.23, since we need to support both 20 and 23, and the metrics2 API is incompatible.

          OK, you can add metrics2.1 support in 0.20x along with the older metrics2.0 API that'd be deprecated. HBase can use the nice new metrics 2.1 API for both 0.20x and 0.23+ lines. I prefer this instead of the other way around to keep the newer branches clean

          Show
          Luke Lu added a comment - HBase is stuck using metrics1 until all of our users move to 0.23, since we need to support both 20 and 23, and the metrics2 API is incompatible. OK, you can add metrics2.1 support in 0.20x along with the older metrics2.0 API that'd be deprecated. HBase can use the nice new metrics 2.1 API for both 0.20x and 0.23+ lines. I prefer this instead of the other way around to keep the newer branches clean
          Hide
          Todd Lipcon added a comment -

          The only two API changes that affect plugins are:

          It's not just sink plugins that are affected, but any applications that want to build against metrics. For example, HBase is stuck using metrics1 until all of our users move to 0.23, since we need to support both 20 and 23, and the metrics2 API is incompatible.

          203-205 and some previous Y releases

          Serves them right for developing a major new subsystem on 20 instead of trunk

          Show
          Todd Lipcon added a comment - The only two API changes that affect plugins are: It's not just sink plugins that are affected, but any applications that want to build against metrics. For example, HBase is stuck using metrics1 until all of our users move to 0.23, since we need to support both 20 and 23, and the metrics2 API is incompatible. 203-205 and some previous Y releases Serves them right for developing a major new subsystem on 20 instead of trunk
          Hide
          Luke Lu added a comment -

          can't we backport the improvements into 20x as well? What's the point of having them in 20x if no one can adopt them without breaking in the next version?

          Well, backporting to 20x say 206 would break existing plugins in production for previous 20x releases (203-205 and some previous Y releases). 0.20 to 0.23 is a considered a major release change and people expect things (especially none end-user facing stuff like metrics) break a little 0.23 already requires major deployment/config changes, of which metrics is a only a small part.

          Show
          Luke Lu added a comment - can't we backport the improvements into 20x as well? What's the point of having them in 20x if no one can adopt them without breaking in the next version? Well, backporting to 20x say 206 would break existing plugins in production for previous 20x releases (203-205 and some previous Y releases). 0.20 to 0.23 is a considered a major release change and people expect things (especially none end-user facing stuff like metrics) break a little 0.23 already requires major deployment/config changes, of which metrics is a only a small part.
          Hide
          Luke Lu added a comment -

          Some examples

          For new code (0.23+), the new style (with annotations) API is recommended.

          The only two API changes that affect plugins are:

          1. Metric -> AbstractMetric because I decide to use Metric for annotation.
          2. MetricsVisitor method signatures because I didn't understand Java generics very well
          Show
          Luke Lu added a comment - Some examples For new code (0.23+), the new style (with annotations) API is recommended. The only two API changes that affect plugins are: Metric -> AbstractMetric because I decide to use Metric for annotation. MetricsVisitor method signatures because I didn't understand Java generics very well
          Hide
          Todd Lipcon added a comment -

          it's unfortunate that such a new API in 20x is already incompatible with 23... can't we backport the improvements into 20x as well? What's the point of having them in 20x if no one can adopt them without breaking in the next version?

          Show
          Todd Lipcon added a comment - it's unfortunate that such a new API in 20x is already incompatible with 23... can't we backport the improvements into 20x as well? What's the point of having them in 20x if no one can adopt them without breaking in the next version?
          Hide
          Luke Lu added a comment -

          Actually the metrics2 framework is first checked into 20x branch and then some API evolved for good reasons in trunk and then 0.23, which was explicitly marked as incompatible changes. I personally don't want to support 0.20x style plugins and prefer giving a more explicit upgrade message, which is reasonable. Supporting both would make 0.23/trunk code very ugly.

          Show
          Luke Lu added a comment - Actually the metrics2 framework is first checked into 20x branch and then some API evolved for good reasons in trunk and then 0.23, which was explicitly marked as incompatible changes. I personally don't want to support 0.20x style plugins and prefer giving a more explicit upgrade message, which is reasonable. Supporting both would make 0.23/trunk code very ugly.
          Hide
          Todd Lipcon added a comment -

          Some examples:

          • JvmMetricsSource vs JvmMetrics
          • MetricMutableStat* vs MutableStat*
          • MetricsBuilder vs MetricsCollector
            maybe some others
          Show
          Todd Lipcon added a comment - Some examples: JvmMetricsSource vs JvmMetrics MetricMutableStat* vs MutableStat* MetricsBuilder vs MetricsCollector maybe some others

            People

            • Assignee:
              Unassigned
              Reporter:
              Todd Lipcon
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development