Michael Stack created HBASE-24544:
-
Summary: Recommend upping zk jute.maxbuffer in all but minor
installs
Key: HBASE-24544
URL: https://issues.apache.org/jira/browse/HBASE-24544
Project: HBase
Andrew Kyle Purtell created HBASE-24543:
---
Summary: ScheduledChore logging is too chatty, replace with metrics
Key: HBASE-24543
URL: https://issues.apache.org/jira/browse/HBASE-24543
Project:
[
https://issues.apache.org/jira/browse/HBASE-24534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Dimiduk resolved HBASE-24534.
--
Fix Version/s: 3.0.0-alpha-1
Resolution: Fixed
> Delete reference off to Hadoop wiki's
Nick Dimiduk created HBASE-24542:
Summary: Update anonymous git url on website
Key: HBASE-24542
URL: https://issues.apache.org/jira/browse/HBASE-24542
Project: HBase
Issue Type: Task
[
https://issues.apache.org/jira/browse/HBASE-24400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bharath Vissapragada resolved HBASE-24400.
--
Fix Version/s: master
Resolution: Fixed
> Automatically download CMake
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,
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
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
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
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
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
Constantin-Catalin Luca created HBASE-24541:
---
Summary: Add support to run LoadIncrementalHFiles in a distributed
manner
Key: HBASE-24541
URL: https://issues.apache.org/jira/browse/HBASE-24541
Oh great. Thanks for pointing that out. I think that is what is the exact
place that the perf bottleneck was found.
Regards
Ram
On Thu, Jun 11, 2020 at 4:29 PM 张铎(Duo Zhang) wrote:
> Oh, good. I recall that there is a related issue but I just forget the
> title so I can not find it...
>
>
Oh, good. I recall that there is a related issue but I just forget the
title so I can not find it...
Thanks for chimming in.
OpenInx 于2020年6月11日周四 下午6:39写道：
> Hi Zheng wang.
>
> Hope this issue will be helpful for you.
> https://issues.apache.org/jira/browse/HBASE-21657
> Thanks.
>
> On Tue,
Hi Zheng wang.
Hope this issue will be helpful for you.
https://issues.apache.org/jira/browse/HBASE-21657
Thanks.
On Tue, Jun 9, 2020 at 5:53 PM Anoop John wrote:
> Thanks for the detailed analysis and update zheng wang.
> >The code line below in StoreScanner.next() cost about 100ms in v2.1,
15 matches
Mail list logo
