[
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
