Bo Cui created HBASE-18694:
--
Summary: Ha mode master switch causes region not online
Key: HBASE-18694
URL: https://issues.apache.org/jira/browse/HBASE-18694
Project: HBase
Issue Type: Bug
[
https://issues.apache.org/jira/browse/HBASE-14910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Appy resolved HBASE-14910.
--
Resolution: Duplicate
Fix Version/s: HBASE-18640
> Create base hbase-mapred and hbase-io modules, move
huaxiang sun created HBASE-18693:
Summary: adding an option to restore_snapshot to move mob files
from archive dir to working dir
Key: HBASE-18693
URL: https://issues.apache.org/jira/browse/HBASE-18693
stack created HBASE-18692:
-
Summary: [compat 1-2] ByteBufferUtils.copyFromBufferToBuffer goes
from void to int
Key: HBASE-18692
URL: https://issues.apache.org/jira/browse/HBASE-18692
Project: HBase
stack created HBASE-18691:
-
Summary: [compat 1-2] HCD remove and removeConfiguration change
return type
Key: HBASE-18691
URL: https://issues.apache.org/jira/browse/HBASE-18691
Project: HBase
Issue
bq. ...but if we are recommending HLC for user tables, we have to also do
end-to-end testing to demonstrate that perf is not affected by HLC.
Agree. I think the only way of doing it right now is running ycsb
with/without HLC.
If it highlights an issue, it means there is one (there can't be false
HLC will never be able to match the throughput for the system clock of
course. I was expecting the perf to be in the 2-3x slower range, not more
than an order of magnitude difference. The current perf is definitely
acceptable for meta updates, but if we are recommending HLC for user
tables, we
Chia-Ping Tsai created HBASE-18690:
--
Summary: Replace o.a.h.c.InterfaceAudience by
o.a.h.h.c.InterfaceAudience
Key: HBASE-18690
URL: https://issues.apache.org/jira/browse/HBASE-18690
Project: HBase
Ted Yu created HBASE-18689:
--
Summary: BackupClientFactory class misses InterfaceAudience
annotation
Key: HBASE-18689
URL: https://issues.apache.org/jira/browse/HBASE-18689
Project: HBase
Issue
Appy created HBASE-18688:
Summary: Upgrade commons-codec to 1.10
Key: HBASE-18688
URL: https://issues.apache.org/jira/browse/HBASE-18688
Project: HBase
Issue Type: Task
Reporter: Appy
It's true that hlc clock is very slower than system, but is it really a
bottleneck? I mean 7mil ops/sec with 16 threads doesn't sound bottleneck
because:
- It's like 70 times of any RS' throughput (assuming 100k write throughput)
- It's certainly enough for meta operations.
What say?
But i
[
https://issues.apache.org/jira/browse/HBASE-18687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack resolved HBASE-18687.
---
Resolution: Fixed
Pushed to branch-2 and master.
> Add @since 2.0.0 to new classes
>
stack created HBASE-18687:
-
Summary: Add @since 2.0.0 to new classes
Key: HBASE-18687
URL: https://issues.apache.org/jira/browse/HBASE-18687
Project: HBase
Issue Type: Sub-task
Reporter:
Created a ticket: Improve HLC implementation performance (
https://issues.apache.org/jira/browse/HBASE-18686).
On Fri, Aug 25, 2017 at 11:53 AM, Enis Söztutar wrote:
> Indeed it seems like a perf improvement in the code HLC clock is needed
> before the merge. Do you mind
Amit Patel created HBASE-18686:
--
Summary: Improve HLC implementation performance
Key: HBASE-18686
URL: https://issues.apache.org/jira/browse/HBASE-18686
Project: HBase
Issue Type: Sub-task
Indeed it seems like a perf improvement in the code HLC clock is needed
before the merge. Do you mind creating a sub ticket for this.
Enis
On Fri, Aug 25, 2017 at 10:54 AM, Amit Patel
wrote:
> Just as an update with regard to performance: getting the time from or
>
stack created HBASE-18685:
-
Summary: Update refguide release candidate making section; stale
and bad instruction
Key: HBASE-18685
URL: https://issues.apache.org/jira/browse/HBASE-18685
Project: HBase
Just as an update with regard to performance: getting the time from or
updating the hybrid logical clock is quite expensive (see clocks
microbenchmark
On Fri, Aug 25, 2017 at 10:06 AM, Mike Drob wrote:
> +1 (non-binding)
>
> Signatures and checksums good.
>
> LICENSE question... do we actually bundle jquery, asciidoctor, and the orca
> logo here? I didn't see them anywhere.
> CHANGES is mostly blank... If we don't use it, get
stack created HBASE-18684:
-
Summary: [hbase-thirdparty] Remove CHANGES, update NOTICES
Key: HBASE-18684
URL: https://issues.apache.org/jira/browse/HBASE-18684
Project: HBase
Issue Type: Task
+1 (non-binding)
Checksum, signature good.
Built hbase pointing to staging repo.
I agree with Mike's LICENSE and CHANGES suggestions.
Peter
On Thu, Aug 24, 2017 at 12:46 AM, Stack wrote:
> This is a minor update to hbase-thirdparty, our little side project of
> relocated
+1 (non-binding)
Signatures and checksums good.
LICENSE question... do we actually bundle jquery, asciidoctor, and the orca
logo here? I didn't see them anywhere.
CHANGES is mostly blank... If we don't use it, get rid of it in the next
version.
Verified an hbase compile against this version,
Agreed this part of code can be improved.
On Fri, Aug 25, 2017 at 3:57 AM, Lars George wrote:
> Hi,
>
> I am looking at the replication code, and it has this line:
>
> this.queueSizePerGroup = this.conf.getInt("hbase.regionserver.maxlogs",
> 32);
>
> This drives the queue
Hi,
I am looking at the replication code, and it has this line:
this.queueSizePerGroup = this.conf.getInt("hbase.regionserver.maxlogs", 32);
This drives the queue size accepting more WAL files. But we have a
different computation now, using the heap size instead, so often have
a maxlogs > 32 in
Peter Somogyi created HBASE-18683:
-
Summary: Upgrade hbase to commons-math 3
Key: HBASE-18683
URL: https://issues.apache.org/jira/browse/HBASE-18683
Project: HBase
Issue Type: Improvement
[
https://issues.apache.org/jira/browse/HBASE-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-16320.
---
Resolution: Won't Fix
Resolve as all sub tasks have been cancelled.
> Revisit scan semantics and
[
https://issues.apache.org/jira/browse/HBASE-16323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-16323.
---
Resolution: Won't Fix
In HBASE-18169 we decided to disable the custom StoreScanner creation from CP
[
https://issues.apache.org/jira/browse/HBASE-16322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-16322.
---
Resolution: Won't Fix
As said previously, we do have some usages which use raw scan and filter
[
https://issues.apache.org/jira/browse/HBASE-18681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-18681.
---
Resolution: Duplicate
Finally I found that it is possible to remove the LegacyScanQueryMatcher in
[
https://issues.apache.org/jira/browse/HBASE-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Minwoo Kang resolved HBASE-18454.
-
Resolution: Duplicate
> RegionServer Do not close file descriptor when using shortcircuit
>
[
https://issues.apache.org/jira/browse/HBASE-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Minwoo Kang reopened HBASE-18454:
-
> RegionServer Do not close file descriptor when using shortcircuit
>
[
https://issues.apache.org/jira/browse/HBASE-18454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Minwoo Kang resolved HBASE-18454.
-
Resolution: Information Provided
Actually, This is HDFS issue.
Please check HDFS-12204.
>
[
https://issues.apache.org/jira/browse/HBASE-15374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang resolved HBASE-15374.
---
Resolution: Fixed
Assignee: Duo Zhang
Thanks for the reminder [~chia7712].
Resolve as all
33 matches
Mail list logo