On Thu, Oct 26, 2017 at 1:52 PM Josh Elser wrote:
> That's the million-dollar question, now isn't it! :)
>
> Something to hbase-metrics-api/README.md? A chapter in the book?
>
In the Javadoc makes the most sense to me. I don’t think people would check
the book. Apply, where did you try and fail
On 10/26/17 1:55 PM, Apekshit Sharma wrote:
bq. .integration with metrics-library1 to support the metrics platform
for their $business1. $business2 might want to use metrics-library2
Makes sense Josh.
bq. One final concern, bundling our "default" DropwizardMetrics 3-based
implementation
That's the million-dollar question, now isn't it! :)
Something to hbase-metrics-api/README.md? A chapter in the book?
Happy to try to translate some of this info into something more "permanent"
On 10/26/17 12:59 AM, Misty Stanley-Jones wrote:
If we keep it as is, how and where can we capture t
bq. .integration with metrics-library1 to support the metrics platform
for their $business1. $business2 might want to use metrics-library2
Makes sense Josh.
bq. One final concern, bundling our "default" DropwizardMetrics 3-based
implementation could cause headaches for users who want to b
If we keep it as is, how and where can we capture this knowledge to save
future contributors from having to ask again?
On Wed, Oct 25, 2017 at 9:22 AM Josh Elser wrote:
> :) no worries, Appy. These are good questions.
>
> It really comes down to the question: would HBase ever provide multiple
>
:) no worries, Appy. These are good questions.
It really comes down to the question: would HBase ever provide multiple
metrics implementations for users?
As we know metrics in HBase now, there isn't any reason to support
multiple implementations of metrics. We have one implementation which is
That issue renamed a bunch of what used to be there only for
hbase-hadoop-compat. HBASE-6405 is the start of the chain.
Currently though I don't see any reason for them to be in separate modules
unless we think hadoop will make another breaking change to the metrics
classes.
On Tue, Oct 24, 2017
Hi Josh
You're right that naming doesn't make it clear, but Enis added a really
great description in README of hbase-metrics-api to explain what's in each
module. However it's not obvious why are we splitting things into separate
module, as opposed to say, separating implementation in a separate "
Hey Appy,
I think Enis essentially copied what I was originally trying to do. Up
in Avatica[1], I made a similar API Maven module which just had
interfaces. The implementation was them split up into a different module
to avoid the implementation details of the API (specifically, using
Dropwiz
Hey Elliott, good to see you around :)
Btw, this is new stuff added in HBASE-9774 which was committed to only 2.0.
Made it to 1.4 too later (HBASE-18060).
-- Appy
On Tue, Oct 24, 2017 at 4:16 PM, Elliott Clark wrote:
> The weird module dance with reflection came from needing to extend inner
>
The weird module dance with reflection came from needing to extend inner
hadoop classes on multiple different versions. This was back when HBase had
to support hadoop < 1, hadoop 1.x, and hadoop 2.x. When we dropped older
hadoop versions then things got easier.
On Tue, Oct 24, 2017 at 3:09 PM, Ape
Hi
Am confused why do we have this weird circular dependency between the two
modules: hbase-metrics-api & hbase-metrics. And since maven doesn't allow
it explicitly, this was tucked and hidden by using reflection?
MetricRegistriesImpl[hbase-metrics] implements
MetricRegistries[hbase-metrics-api].
12 matches
Mail list logo
