hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6412) Move external servers to metrics2 (thrift,thrift2,rest)
Date Tue, 28 Aug 2012 06:07:07 GMT

    [ https://issues.apache.org/jira/browse/HBASE-6412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13442979#comment-13442979
] 

Elliott Clark commented on HBASE-6412:
--------------------------------------

bq.Why is it called a CompatibilityFactory? Thats pretty generic. Is it indeed compatibility
for all things (It looks like it could be 'generic')?

The CompatitibitySingletonFactory is there for classes from the compatibility jars that will
only ever be instantiated once.  The CompatibilityFactory is for classes from the compatibility
jars that can be created multiple times.

The CompatibilitySingletonFactory is has been checked in.  I just created the CompatibilityFactory
here for MetricsAssertHelper since I didn't want multiple Junit tests to share the same instances
of the asserts helper.

bq.Is it good having 'Singleton' in name of a class? CompatibilitySingletonFactory.
Singletons stink however with the way the JMX stuff works once an MBean is registered hadoop
metrics complains loudly whenever we try and register another, so a singleton is the only
solution.  In fact I might need to make it so that ThriftMetricsSourceFactoryImpl's only return
a singleton.

bq.What is a MetricsAssertHelper? Sounds painful!
Basically with the way the hadoop1/2 metrics2 system is there's no really clean way to get
the value of a single metric that's compatible across the two versions (Names of rates NumOps
vs num_ops and other aweseome....... things make it a challenge).  So the MetricsAssertHelper
class is just a class that can be used to test easily that our BaseMetricSource's have a metric
with some value.  Hadoop has their version(https://github.com/apache/hadoop-common/blob/trunk/hadoop-common-project/hadoop-common/src/test/java/org/apache/hadoop/test/MetricsAsserts.java)
however we needed a few more features (greater than and less than) and we needed them to be
compatible so I created an HBase version.  

bq.Do we have to do the Impl suffix on things like RESTMetricsSourceImpl? Its inelegant. It
does get the point across though so I'm not all against it.
The most often used means that I know about to keep class/interface names from clashing is
either to use the Impl class suffix or to put the implementation into a different namespace.
 I'm up for whatever you think is the best.

bq.This is funny though: ThriftServerMetricsSourceFactoryImpl Maybe you could get a few more
keywords on the class name (smile)?
Needs the Abstract word in there.
                
> Move external servers to metrics2 (thrift,thrift2,rest)
> -------------------------------------------------------
>
>                 Key: HBASE-6412
>                 URL: https://issues.apache.org/jira/browse/HBASE-6412
>             Project: HBase
>          Issue Type: Sub-task
>    Affects Versions: 0.96.0
>            Reporter: Elliott Clark
>            Assignee: Elliott Clark
>            Priority: Blocker
>         Attachments: HBASE-6412-0.patch
>
>
> Implement metrics2 for all the external servers:
> * Thrift
> * Thrift2
> * Rest

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message