Fixed: HBase Generate Website

Build status: Fixed If successful, the website and docs have been generated. If failed, skip to the bottom of this email. Use the following commands to download the patch and apply it to a clean branch based on origin/asf-site. If you prefer to keep the hbase-site repo around permanently, you

[jira] [Resolved] (HBASE-14107) Procedure V2 - Administrative Task: Provide an API to List all procedures

[ https://issues.apache.org/jira/browse/HBASE-14107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang resolved HBASE-14107. Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 > Procedure

[jira] [Resolved] (HBASE-14108) Procedure V2 - Administrative Task: provide an API to abort a procedure

[ https://issues.apache.org/jira/browse/HBASE-14108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang resolved HBASE-14108. Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 > Procedure

[jira] [Resolved] (HBASE-14432) Procedure V2 - enforce ACL on procedure admin tasks

[ https://issues.apache.org/jira/browse/HBASE-14432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang resolved HBASE-14432. Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 > Procedure

[jira] [Resolved] (HBASE-14488) Procedure V2 - shell command to abort a procedure

[ https://issues.apache.org/jira/browse/HBASE-14488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang resolved HBASE-14488. Resolution: Fixed Fix Version/s: 1.1.3 1.2.0 > Procedure

[jira] [Resolved] (HBASE-14487) Procedure V2 - shell command to list all procedures

[ https://issues.apache.org/jira/browse/HBASE-14487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Yuan Jiang resolved HBASE-14487. Resolution: Fixed > Procedure V2 - shell command to list all procedures >

[jira] [Created] (HBASE-15074) Zombie maker to test zombie detector

stack created HBASE-15074: - Summary: Zombie maker to test zombie detector Key: HBASE-15074 URL: https://issues.apache.org/jira/browse/HBASE-15074 Project: HBase Issue Type: Sub-task

Re: [VOTE] HBase 1.2.0 RC0

Folks, please comment on the relevant jiras and not on the VOTE thread. On Wed, Jan 6, 2016 at 11:49 AM, Mikhail Antonov wrote: > +1 to include patches which improve region normalization. Since it's new > functionality for 1.2, should be low risk (no regressions). > >

Re: [VOTE] HBase 1.2.0 RC0

+1 to include patches which improve region normalization. Since it's new functionality for 1.2, should be low risk (no regressions). -Mikhail On Wed, Jan 6, 2016 at 8:37 AM, Ted Yu wrote: > Please also consider including HBASE-15073 in the next RC. > > This JIRA gives

Re: [VOTE] HBase 1.2.0 RC0

You're right, sorry. On Wed, Jan 6, 2016 at 10:09 AM, Sean Busbey wrote: > Folks, please comment on the relevant jiras and not on the VOTE thread. > > On Wed, Jan 6, 2016 at 11:49 AM, Mikhail Antonov > wrote: > > > +1 to include patches which improve

Re: identifying source of region split request

Adding this tracing information to know who initiated split is in general useful thing. Right now though I'm not sure I see how that would help to make better normalization decisions? Region split failure implies underlying FS issue? Any examples/ideas? Kind of..collect statistics to blacklist

Re: identifying source of region split request

bq. collect statistics to blacklist some RSs with high failure rate The metadata would help pinpoint the regions which consistently fail split (merge) in the recent past. The failure could be due to corrupt HFile(s) or other reason. Having the statistics would also help normalizer avoid the

Re: identifying source of region split request

Yeah, I see. Btw, in scenario you described, is splitting and subsequent merging a necessarily bad thing? If data expiration happens not that often, having more evenly sized regions in between major collections isn't worth it? On Wed, Jan 6, 2016 at 10:23 AM, Ted Yu wrote:

Re: [VOTE] HBase 1.2.0 RC0

Please also consider including HBASE-15073 in the next RC. This JIRA gives finer grained control over region normalization. Since 1.2.0 would be the first release with region normalization feature, it would be nice to get user facing aspect straightened out. Thanks On Tue, Jan 5, 2016 at 1:47

[jira] [Created] (HBASE-15076) make the HRegion.getScanner(Scan scan, List additionalScanners, boolean copyCellsFromSharedMem) to be public

liu ming created HBASE-15076: Summary: make the HRegion.getScanner(Scan scan, List additionalScanners, boolean copyCellsFromSharedMem) to be public Key: HBASE-15076 URL:

[jira] [Created] (HBASE-15075) Allow region split request to carry metadata

Ted Yu created HBASE-15075: -- Summary: Allow region split request to carry metadata Key: HBASE-15075 URL: https://issues.apache.org/jira/browse/HBASE-15075 Project: HBase Issue Type: Improvement

Parallel scanning of snapshots using hbase client api

Using the client api, we can scan the snapshot using a single scanner. We currently create an instance of TableSnapshotScanner providing it with a unique dir location per scanner. We are currently on cdh 5.4.5 and using the hbase 1.0.0-cdh5.4.5 api. In order to get desired throughput, we tried to

Re: identifying source of region split request

Could we use Procedure V2 framework to do split? It seems to be a great work... 2016-01-07 4:35 GMT+08:00 Ted Yu : > bq. is splitting and subsequent merging a necessarily bad thing? > > Please note that merging may happen before the size of R1 (R2) drops to > zero. Meaning,

Re: identifying source of region split request

at some point we can use proc-v2 for split/merge HBASE-14551/HBASE-14552 but I'm a bit behind the schedule with the framework. me and Stephen are working to get in that direction. but it is probably a month or two away Matteo On Wed, Jan 6, 2016 at 7:49 PM, Heng Chen

Re: identifying source of region split request

bq. is splitting and subsequent merging a necessarily bad thing? Please note that merging may happen before the size of R1 (R2) drops to zero. Meaning, there may be churn in normalization activity. I would say that the normalization in the scenario below is premature. Cheers On Wed, Jan 6, 2016

Re: Compact after manual flush broken in 1.0+?

Unable to find it. Feel free to open. JMS 2015-12-31 12:36 GMT-05:00 Jean-Marc Spaggiari : > I think there is one. I will search later today... > Le 2015-12-31 11:35 AM, "Ted Yu" a écrit : > >> A brief search turned up no hit. >> >> Please go

Re: Compact after manual flush broken in 1.0+?

>> Normally HBase triggers a compaction after a manual flush (of a region or table). Yes, I found this while working on FIFOCompaction test. Manual flush does not trigger compaction. But wait, we can manually trigger compaction if we need :). -Vlad On Wed, Jan 6, 2016 at 1:23 PM, Jean-Marc