Hi,
Currently the IA for MutableSizeHistogram and MutableTimeHistogram is
private. We want to use these classes in PHOENIX project and I thought we
can leverage the existing implementation from hbase histo implementation.
IIUC the private IA can't be used in other projects. Proposing to make it
Lim
My only concern is that you can't just mark these two classes a
LimitedPrivate for Phoenix -- you would also have to mark
MutableRangeHistogram, MutableHistogram (and the rest of the class
hierarchy) to make sure that we don't make it super confusing as to what
comes from LimitedPrivate classes
I was just about to reply with the same -- Josh is faster :) +1 on
considering the full surface area of the APIs being exposed.
I also wonder if exposing the metrics infrastructure is something of
interest more broadly than Phoenix. Seems like any coprocessor might want
to provide or monitor some
hbase-metrics-api is available for coprocessors already and interfaces
within are already LimitedPrivate(COPROC). However, that package is mostly
interface and seems geared toward consuming metrics instantiated and
registered via private stuff. Or, rather, I didn't see how Phoenix could choose
whic
Sounds reasonable to me!
On 6/11/20 1:06 PM, Andrew Purtell wrote:
hbase-metrics-api is available for coprocessors already and interfaces
within are already LimitedPrivate(COPROC). However, that package is mostly
interface and seems geared toward consuming metrics instantiated and
registered via
Couple points:
1. I like Andrew's proposed solution, and we should do it, but I'm not sure
it's sufficient for Rushabh's purposes because of semver rules. Phoenix
supports HBase 1.3 -1.5 (soon to add 1.6) and HBase 2.0 (soon to gain 2.1
and 2.2, with 2.3 coming shortly after its release here.) If
That's unfortunate, but needs must, IMHO.
A potential benefit of also marking the impls LP(COPROC) is this captures
any implicit dependency on semantics and functionality of the
implementation classes not directly exposed in the hbase-metrics-api facade.
So, let's do both? (Facade improvement, ra
+1 to "let's do both"
FWIW, our stance on semver is to "strive to follow it", not "must follow
it". I think when we have a concrete change we can look at, we could
make the call to say whether or not we feel comfortable bringing this
into maintenance release lines. The circumstances of this re
