Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
HBase >> mail # dev >> deprecating (old) metrics in favor of metrics2 framework


Copy link to this message
-
Re: deprecating (old) metrics in favor of metrics2 framework
https://issues.apache.org/jira/browse/HADOOP-7734

As far as I can tell this basically sinks all Metrics2 usage in HBase.

On Tue, Jul 10, 2012 at 3:24 PM, Alex Baranau <[EMAIL PROTECTED]>wrote:

> > If there's considerable pain or overhead in having both
> > implementations live in parallel, maybe it's worth doing a straight
> > switch over in 0.96.
>
> As far as I can tell, they can live together easily. This should not be a
> big issue. E.g. it should be much smaller issue than the fact that code
> implemented on top of metrics2 will not compile against 1.0+, 2.0+ and 3.0+
> hadoop at the same time because class names, etc. changed between 1.0 and
> 2.0. But that's a separate story, will look at it tomorrow (Ted pointed me
> to smth to look at).
>
> Alex Baranau
>
> On Tue, Jul 10, 2012 at 5:03 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
>
> > Points taken.
> >
> > Thanks for the education of metrics framework history.
> >
> > On Tue, Jul 10, 2012 at 1:55 PM, Gary Helmling <[EMAIL PROTECTED]>
> > wrote:
> >
> > > I agree that having a new metrics2 implementation in 0.96 would be
> > > great to see and seems like a natural fit.  I'm 100% for that.  But I
> > > do think that having metrics2 and (deprecated) metrics v1 in the same
> > > release would be very helpful to users making the transition.  So to
> > > me it seems more natural for 0.96 to be that release with both
> > > implementations, since that's where it seems like the metrics2
> > > implementation will land.
> > >
> > > Otherwise it seems like we risk introducing the same disruptions that
> > > Hadoop did when metrics2 initially replaced the metrics v1
> > > implementation, instead of living along side.  This did cause us as a
> > > project some trouble until metrics v1 was added back in.  So it would
> > > be unfortunate to repeat the same mistake ourselves.
> > >
> > > If there's considerable pain or overhead in having both
> > > implementations live in parallel, maybe it's worth doing a straight
> > > switch over in 0.96.  I haven't looked at the differences enough
> > > myself to know.  But otherwise it seems like an easier migration path
> > > to deprecate v1 in 0.96 and remove the release after.
> > >
> > >
> > > On Tue, Jul 10, 2012 at 1:35 PM, Ted Yu <[EMAIL PROTECTED]> wrote:
> > > > Gary:
> > > > Your comment makes sense.
> > > >
> > > > Part of this poll originates from the fact that 0.96 is our
> singularity
> > > > release. RPC, coprocessor, etc have undergone considerable changes.
> > > > Users migrating to 0.96 would have to deal with a lot of updates in
> > their
> > > > codebase.
> > > >
> > > > It seems to me that doing all upgrades in one shot is almost the same
> > as
> > > > upgrading components other than metrics framework.
> > > >
> > > > Cheers
> > > >
> > > > On Tue, Jul 10, 2012 at 1:29 PM, Gary Helmling <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > >> >
> > > >> > Whether we support 2 (actually more than 2) metrics frameworks in
> > 0.96
> > > >> can
> > > >> > be debated in the next 2 months.
> > > >> >
> > > >>
> > > >> I'm not sure I agree that deprecating without having something in
> > > >> place for users to move to makes sense.
> > > >>
> > > >> > As Todd mentioned in the thread 'HBase 0.94.1', we will try our
> best
> > > to
> > > >> > keep JMX interface the same across 0.94 and 0.96. Does this
> somehow
> > > >> reduce
> > > >> > the concern you raised ?
> > > >> >
> > > >>
> > > >> I think that maintaining consistency with the existing JMX naming
> > > >> conventions (to the extent possible) is important for operational
> > > >> concerns, but it's independent of the MetricsContext question and
> the
> > > >> question of whether other metrics classes of our own need a proper
> > > >> deprecation cycle.
> > > >>
> > > >> > As for using MetricsContext, I assume the user also uses hadoop in
> > > his /
> > > >> > her deployment. Then he / she should be aware of the deprecation
> of
> > > >> > metrics.* classes in both hadoop 1.0 and 2.0
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB