[jira] [Commented] (HBASE-18497) Add clock type to proto message for HLC region open/close
[
https://issues.apache.org/jira/browse/HBASE-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112231#comment-16112231
]
Hadoop QA commented on HBASE-18497:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m
10s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
18s{color} | {color:green} HBASE-14070.HLC passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
33s{color} | {color:green} HBASE-14070.HLC passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m
56s{color} | {color:green} HBASE-14070.HLC passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
46s{color} | {color:green} HBASE-14070.HLC passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
6s{color} | {color:red} hbase-protocol-shaded in HBASE-14070.HLC has 27 extant
Findbugs warnings. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
54s{color} | {color:red} hbase-server in HBASE-14070.HLC has 10 extant Findbugs
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
59s{color} | {color:green} HBASE-14070.HLC passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
16s{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
25s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
15s{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
26s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 15s{color} |
{color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 26s{color} |
{color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 15s{color}
| {color:red} hbase-client in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 26s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m
58s{color} | {color:red} The patch causes 60 errors with Hadoop v2.6.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
56s{color} | {color:red} The patch causes 60 errors with Hadoop v2.6.2. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
54s{color} | {color:red} The patch causes 60 errors with Hadoop v2.6.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
51s{color} | {color:red} The patch causes 60 errors with Hadoop v2.6.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m
55s{color} | {color:red} The patch causes 60 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
58s{color} | {color:red} The patch causes 60 errors with Hadoop v2.7.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
5s{color} | {color:red} The patch causes 60 errors with Hadoop v2.7.2. {color} |
| {color:red}-1{color} | {color:red}
[jira] [Updated] (HBASE-18511) Default no regions on master
[ https://issues.apache.org/jira/browse/HBASE-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18511: -- Attachment: HBASE-18511.master.001.patch > Default no regions on master > > > Key: HBASE-18511 > URL: https://issues.apache.org/jira/browse/HBASE-18511 > Project: HBase > Issue Type: Task > Components: master >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18511.master.001.patch > > > Let this be umbrella issue for no-regions-on-master as default deploy (as it > was in branch-1). > Also need to make sure we can run WITH regions on master; in particular > system tables with RPC short-circuit as it is now in hbase master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18511) Default no regions on master
[ https://issues.apache.org/jira/browse/HBASE-18511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112229#comment-16112229 ] stack commented on HBASE-18511: --- .001 just disables master serving regions. Probably breaks a load of tests. Lets see. > Default no regions on master > > > Key: HBASE-18511 > URL: https://issues.apache.org/jira/browse/HBASE-18511 > Project: HBase > Issue Type: Task > Components: master >Reporter: stack >Assignee: stack >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18511.master.001.patch > > > Let this be umbrella issue for no-regions-on-master as default deploy (as it > was in branch-1). > Also need to make sure we can run WITH regions on master; in particular > system tables with RPC short-circuit as it is now in hbase master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18231) Deprecate and throw unsupported operation when Admin#closeRegion is called.
[
https://issues.apache.org/jira/browse/HBASE-18231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112226#comment-16112226
]
Ted Yu commented on HBASE-18231:
For AsyncAdmin.java :
{code}
+ * @deprecated Since 2.0. Will be removed in 3.0. Use {@link
#unassign(byte[], boolean)} instead.
*/
CompletableFuture closeRegion(byte[] regionName,
Optional serverName);
{code}
Since 2.0 has not been released. The above method can be removed, right ?
> Deprecate and throw unsupported operation when Admin#closeRegion is called.
> ---
>
> Key: HBASE-18231
> URL: https://issues.apache.org/jira/browse/HBASE-18231
> Project: HBase
> Issue Type: Sub-task
> Components: Admin
>Affects Versions: 2.0.0
>Reporter: stack
>Assignee: Appy
>Priority: Critical
> Fix For: 2.0.0, 3.0.0
>
> Attachments: HBASE-18231.master.001.patch,
> HBASE-18231.master.002.patch, HBASE-18231.master.003.patch
>
>
> [~uagashe] tripped over this today. Admin#closeRegion which we used to use in
> branch-1 will cause damage in AMv2 cluster. Instead you need to call unassign
> -- i.e. all cluster ops must go via the Master; no more going direct to
> RegionServer closing regions behind the Master's back.
> Review all Admin ops to see what else skirts Master and deprecate and throw
> unsupported if called.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18470) RetriesExhaustedWithDetailsException#getDesc describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18470: --- Summary: RetriesExhaustedWithDetailsException#getDesc describe is not right (was: `RetriesExhaustedWithDetailsException#getDesc` describe is not right) > RetriesExhaustedWithDetailsException#getDesc describe is not right > -- > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin >Priority: Minor > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16893) Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter
[ https://issues.apache.org/jira/browse/HBASE-16893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-16893: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Push this to master and branch-2 Thanks for the patch. [~rayokota] > Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter > --- > > Key: HBASE-16893 > URL: https://issues.apache.org/jira/browse/HBASE-16893 > Project: HBase > Issue Type: Improvement >Reporter: Robert Yokota >Assignee: Robert Yokota >Priority: Minor > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16893.master.001.patch, > HBASE-16893.master.002.patch, HBASE-16893.master.003.patch > > > This is a performance improvement to use Iterables.removeIf in the > filterRowCells method of DependentColumnFilter as described here: > https://rayokota.wordpress.com/2016/10/20/tips-on-writing-custom-hbase-filters/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18511) Default no regions on master
stack created HBASE-18511: - Summary: Default no regions on master Key: HBASE-18511 URL: https://issues.apache.org/jira/browse/HBASE-18511 Project: HBase Issue Type: Task Components: master Reporter: stack Assignee: stack Priority: Blocker Fix For: 2.0.0 Let this be umbrella issue for no-regions-on-master as default deploy (as it was in branch-1). Also need to make sure we can run WITH regions on master; in particular system tables with RPC short-circuit as it is now in hbase master. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18470: --- Priority: Minor (was: Major) > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin >Priority: Minor > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112221#comment-16112221 ] Chia-Ping Tsai commented on HBASE-18470: +1 > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin >Priority: Minor > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[
https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112218#comment-16112218
]
Hadoop QA commented on HBASE-18470:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
59s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 31s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
42s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 45m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.11.2 Server=1.11.2 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18470 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880164/HBASE-18470.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 67160f3a38ed 3.13.0-116-generic #163-Ubuntu SMP Fri Mar 31
14:13:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 504a1f1 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7909/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7909/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> `RetriesExhaustedWithDetailsException#getDesc` describe is not right
>
>
> Key: HBASE-18470
> URL: https://issues.apache.org/jira/browse/HBASE-18470
> Project: HBase
> Issue Type: Bug
> Components: Client
>
[jira] [Commented] (HBASE-16893) Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter
[ https://issues.apache.org/jira/browse/HBASE-16893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112215#comment-16112215 ] Chia-Ping Tsai commented on HBASE-16893: Will commit it shortly > Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter > --- > > Key: HBASE-16893 > URL: https://issues.apache.org/jira/browse/HBASE-16893 > Project: HBase > Issue Type: Improvement >Reporter: Robert Yokota >Assignee: Robert Yokota >Priority: Minor > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16893.master.001.patch, > HBASE-16893.master.002.patch, HBASE-16893.master.003.patch > > > This is a performance improvement to use Iterables.removeIf in the > filterRowCells method of DependentColumnFilter as described here: > https://rayokota.wordpress.com/2016/10/20/tips-on-writing-custom-hbase-filters/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16893) Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter
[ https://issues.apache.org/jira/browse/HBASE-16893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-16893: --- Summary: Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter (was: Use Iterables.removeIf instead of Iterator.remove in HBase filters) > Use Collection.removeIf instead of Iterator.remove in DependentColumnFilter > --- > > Key: HBASE-16893 > URL: https://issues.apache.org/jira/browse/HBASE-16893 > Project: HBase > Issue Type: Improvement >Reporter: Robert Yokota >Assignee: Robert Yokota >Priority: Minor > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16893.master.001.patch, > HBASE-16893.master.002.patch, HBASE-16893.master.003.patch > > > This is a performance improvement to use Iterables.removeIf in the > filterRowCells method of DependentColumnFilter as described here: > https://rayokota.wordpress.com/2016/10/20/tips-on-writing-custom-hbase-filters/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16893) Use Iterables.removeIf instead of Iterator.remove in HBase filters
[ https://issues.apache.org/jira/browse/HBASE-16893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-16893: --- Fix Version/s: 2.0.0-alpha-2 3.0.0 > Use Iterables.removeIf instead of Iterator.remove in HBase filters > -- > > Key: HBASE-16893 > URL: https://issues.apache.org/jira/browse/HBASE-16893 > Project: HBase > Issue Type: Improvement >Reporter: Robert Yokota >Assignee: Robert Yokota >Priority: Minor > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-16893.master.001.patch, > HBASE-16893.master.002.patch, HBASE-16893.master.003.patch > > > This is a performance improvement to use Iterables.removeIf in the > filterRowCells method of DependentColumnFilter as described here: > https://rayokota.wordpress.com/2016/10/20/tips-on-writing-custom-hbase-filters/ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work started] (HBASE-18467) nightly job needs to comment on jira
[ https://issues.apache.org/jira/browse/HBASE-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-18467 started by Sean Busbey. --- > nightly job needs to comment on jira > > > Key: HBASE-18467 > URL: https://issues.apache.org/jira/browse/HBASE-18467 > Project: HBase > Issue Type: Improvement > Components: community, test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > > follow on from HBASE-18147, need a post action that pings all newly-committed > jiras with result of the branch build -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18467) nightly job needs to comment on jira
[ https://issues.apache.org/jira/browse/HBASE-18467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reassigned HBASE-18467: --- Assignee: Sean Busbey > nightly job needs to comment on jira > > > Key: HBASE-18467 > URL: https://issues.apache.org/jira/browse/HBASE-18467 > Project: HBase > Issue Type: Improvement > Components: community, test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > > follow on from HBASE-18147, need a post action that pings all newly-committed > jiras with result of the branch build -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Work stopped] (HBASE-14845) hbase-server leaks jdk.tools dependency to mapreduce consumers
[ https://issues.apache.org/jira/browse/HBASE-14845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-14845 stopped by Sean Busbey. --- > hbase-server leaks jdk.tools dependency to mapreduce consumers > -- > > Key: HBASE-14845 > URL: https://issues.apache.org/jira/browse/HBASE-14845 > Project: HBase > Issue Type: Bug > Components: build, dependencies >Affects Versions: 2.0.0, 0.98.14, 1.2.0, 1.1.2, 1.3.0, 1.0.3 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-14845.1.patch > > > HBASE-13963 / HBASE-14844 take care of removing leaks of our dependency on > jdk-tools. > Until we move the mapreduce support classes out of hbase-server > (HBASE-11843), we need to also avoid leaking the dependency from that module. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14845) hbase-server leaks jdk.tools dependency to mapreduce consumers
[ https://issues.apache.org/jira/browse/HBASE-14845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-14845: Fix Version/s: (was: 2.0.0) 2.0.0-beta-2 > hbase-server leaks jdk.tools dependency to mapreduce consumers > -- > > Key: HBASE-14845 > URL: https://issues.apache.org/jira/browse/HBASE-14845 > Project: HBase > Issue Type: Bug > Components: build, dependencies >Affects Versions: 2.0.0, 0.98.14, 1.2.0, 1.1.2, 1.3.0, 1.0.3 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Fix For: 1.5.0, 2.0.0-beta-2 > > Attachments: HBASE-14845.1.patch > > > HBASE-13963 / HBASE-14844 take care of removing leaks of our dependency on > jdk-tools. > Until we move the mapreduce support classes out of hbase-server > (HBASE-11843), we need to also avoid leaking the dependency from that module. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18485) Performance issue: ClientAsyncPrefetchScanner is slower than ClientSimpleScanner
[
https://issues.apache.org/jira/browse/HBASE-18485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112175#comment-16112175
]
Hadoop QA commented on HBASE-18485:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
31s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 3s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
38s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}129m 34s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}182m 38s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestHRegion |
| | hadoop.hbase.master.TestMasterFailover |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18485 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880143/HBASE-18485-v4.patch |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 4b649f6502dc 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 504a1f1 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7893/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7893/testReport/ |
| modules | C: hbase-client hbase-server
[jira] [Commented] (HBASE-17049) Find out why AsyncFSWAL issues much more syncs than FSHLog
[ https://issues.apache.org/jira/browse/HBASE-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112174#comment-16112174 ] ramkrishna.s.vasudevan commented on HBASE-17049: Some latest tests showed AsyncWAL to be faster. Let me reconfirm later next week with more tests. > Find out why AsyncFSWAL issues much more syncs than FSHLog > -- > > Key: HBASE-17049 > URL: https://issues.apache.org/jira/browse/HBASE-17049 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Priority: Blocker > Fix For: 2.0.0 > > Attachments: delay-sync.patch > > > https://issues.apache.org/jira/browse/HBASE-16890?focusedCommentId=15647590=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15647590 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18375) The pool chunks from ChunkCreator are deallocated while in pool because there is no reference to them
[ https://issues.apache.org/jira/browse/HBASE-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112173#comment-16112173 ] ramkrishna.s.vasudevan commented on HBASE-18375: [~st...@duboce.net] I have done my review. Am fine with the change (using strong ref always for chunks from pool) considering the fact what [~anastas] has found in her tests. How ever reading the code it seems to me that we have handled things but that seems not the case. I was just waiting for others reviews before we could commit this. > The pool chunks from ChunkCreator are deallocated while in pool because there > is no reference to them > - > > Key: HBASE-18375 > URL: https://issues.apache.org/jira/browse/HBASE-18375 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-alpha-1 >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky >Priority: Critical > Fix For: 2.0.0, 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch, > HBASE-18375-V03.patch, HBASE-18375-V04.patch > > > Because MSLAB list of chunks was changed to list of chunk IDs, the chunks > returned back to pool can be deallocated by JVM because there is no reference > to them. The solution is to protect pool chunks from GC by the strong map of > ChunkCreator introduced by HBASE-18010. Will prepare the patch today. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18375) The pool chunks from ChunkCreator are deallocated while in pool because there is no reference to them
[ https://issues.apache.org/jira/browse/HBASE-18375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan reassigned HBASE-18375: -- Assignee: Anastasia Braginsky > The pool chunks from ChunkCreator are deallocated while in pool because there > is no reference to them > - > > Key: HBASE-18375 > URL: https://issues.apache.org/jira/browse/HBASE-18375 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0-alpha-1 >Reporter: Anastasia Braginsky >Assignee: Anastasia Braginsky >Priority: Critical > Fix For: 2.0.0, 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18375-V01.patch, HBASE-18375-V02.patch, > HBASE-18375-V03.patch, HBASE-18375-V04.patch > > > Because MSLAB list of chunks was changed to list of chunk IDs, the chunks > returned back to pool can be deallocated by JVM because there is no reference > to them. The solution is to protect pool chunks from GC by the strong map of > ChunkCreator introduced by HBASE-18010. Will prepare the patch today. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14498) Master stuck in infinite loop when all Zookeeper servers are unreachable
[
https://issues.apache.org/jira/browse/HBASE-14498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112167#comment-16112167
]
Hadoop QA commented on HBASE-14498:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
21s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
38s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
0s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 45s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
54s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
53s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}114m 31s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}169m 29s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | org.apache.hadoop.hbase.coprocessor.TestHTableWrapper
|
| | org.apache.hadoop.hbase.mapreduce.TestHRegionPartitioner |
| | org.apache.hadoop.hbase.snapshot.TestSnapshotClientRetries |
| | org.apache.hadoop.hbase.master.TestMasterFailover |
| | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| | org.apache.hadoop.hbase.TestFullLogReconstruction |
| | org.apache.hadoop.hbase.coprocessor.TestRegionObserverScannerOpenHook |
| | org.apache.hadoop.hbase.master.TestAssignmentManagerMetrics |
| | org.apache.hadoop.hbase.wal.TestWALFiltering |
| | org.apache.hadoop.hbase.quotas.TestQuotaStatusRPCs |
| | org.apache.hadoop.hbase.TestMultiVersions |
| | org.apache.hadoop.hbase.coprocessor.TestCoprocessorMetrics |
| | org.apache.hadoop.hbase.quotas.TestMasterSpaceQuotaObserver |
| | org.apache.hadoop.hbase.mapreduce.TestCellCounter |
| | org.apache.hadoop.hbase.TestZooKeeper |
| |
[jira] [Commented] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112158#comment-16112158 ] Benedict Jin commented on HBASE-18470: -- Okay, i got it. > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112150#comment-16112150 ] Chia-Ping Tsai commented on HBASE-18470: LGTM. By the way, HBase project doesn't use PR model on github. You have opened a JIRA so the pull request can be closed. > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Jin updated HBASE-18470: - Status: Patch Available (was: Open) [^HBASE-18470.master.002.patch] > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Jin updated HBASE-18470: - Status: Open (was: Patch Available) > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedict Jin updated HBASE-18470: - Attachment: HBASE-18470.master.002.patch > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch, > HBASE-18470.master.002.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18426) nightly job should use independent stages to check supported jdks
[ https://issues.apache.org/jira/browse/HBASE-18426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112141#comment-16112141 ] Sean Busbey commented on HBASE-18426: - bump. could someone take a look here please. > nightly job should use independent stages to check supported jdks > - > > Key: HBASE-18426 > URL: https://issues.apache.org/jira/browse/HBASE-18426 > Project: HBase > Issue Type: Improvement > Components: community, test >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18426.0.patch > > > follow on from HBASE-18147 to handle the lack of multijdk support for unit > tests. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18470) `RetriesExhaustedWithDetailsException#getDesc` describe is not right
[ https://issues.apache.org/jira/browse/HBASE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112138#comment-16112138 ] Benedict Jin commented on HBASE-18470: -- [~chia7712] Sure, that will be better, i will create new patch for it. Thx a lot. > `RetriesExhaustedWithDetailsException#getDesc` describe is not right > > > Key: HBASE-18470 > URL: https://issues.apache.org/jira/browse/HBASE-18470 > Project: HBase > Issue Type: Bug > Components: Client >Reporter: Benedict Jin >Assignee: Benedict Jin > Attachments: HBASE-18470.master.001.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The describe from `RetriesExhaustedWithDetailsException#getDesc` is ` > org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 3 > actions: FailedServerException: 3 times, `, there is a not need ', ' in the > tail. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[
https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112137#comment-16112137
]
Chia-Ping Tsai commented on HBASE-17056:
The master has the same redundant dependency. see
[here|https://github.com/apache/hbase/blob/master/pom.xml#L1716] and
[here|https://github.com/apache/hbase/blob/master/pom.xml#L2026]
{code}
org.apache.hbase.thirdparty
hbase-shaded-miscellaneous
${hbase-thirdparty.version}
{code}
> Remove checked in PB generated files
> -
>
> Key: HBASE-17056
> URL: https://issues.apache.org/jira/browse/HBASE-17056
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Enis Soztutar
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments:
> 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch,
> HBASE-17056.master.001.patch, HBASE-17056.master.002.patch,
> HBASE-17056.master.003.patch, HBASE-17056.master.004.patch,
> HBASE-17056.master.005.patch, HBASE-17056.master.006.patch,
> HBASE-17056.master.006.patch, HBASE-17056.master.007.patch,
> HBASE-17056.master.007.patch
>
>
> Now that we have the new PB maven plugin, there is no need to have the PB
> files checked in to the repo. The reason we did that was to ease up developer
> env setup.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18492) [AMv2] Embed code for selecting highest versioned region server for system table regions in AssignmentManager.processAssignQueue()
[ https://issues.apache.org/jira/browse/HBASE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18492: - Attachment: hbase-18492.master.003.patch Rebased on latest master. > [AMv2] Embed code for selecting highest versioned region server for system > table regions in AssignmentManager.processAssignQueue() > -- > > Key: HBASE-18492 > URL: https://issues.apache.org/jira/browse/HBASE-18492 > Project: HBase > Issue Type: Bug > Components: amv2 >Affects Versions: 2.0.0 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0 > > Attachments: hbase-18492.master.001.patch, > hbase-18492.master.002.patch, hbase-18492.master.003.patch > > > Embed logic of selecting highest versioned region server for system table > regions in AssignmentManager.processAssignQueue(). This way from any section > of the code when system table regions are re/assigned, only highest versioned > RS are candidates for target servers. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112132#comment-16112132 ] stack commented on HBASE-17056: --- It was not needed on master [~chia7712] The cherry-pick was not completely clean. I missed a piece and had to do the addendum to get it in. Thanks. > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch, HBASE-17056.master.004.patch, > HBASE-17056.master.005.patch, HBASE-17056.master.006.patch, > HBASE-17056.master.006.patch, HBASE-17056.master.007.patch, > HBASE-17056.master.007.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[ https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112128#comment-16112128 ] stack commented on HBASE-11768: --- Go for it [~sun.cheney] I was looking at it and seems reasonable. > Register region server in zookeeper by ip address > - > > Key: HBASE-11768 > URL: https://issues.apache.org/jira/browse/HBASE-11768 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Cheney Sun > Labels: patch > Fix For: 2.0.0 > > Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch > > > HBase cluster isn't always setup along with a DNS server. But regionservers > now register their hostnames in zookeeper, which bring some inconvenience > when regionserver isn't in one DNS server. In such situation, clients have to > maintain the ip/hostname mapping in their /etc/hosts files in order to > resolve the hostname returned from zookeeper to the right address. > However, this causes a lot of pain for clients to maintain the mapping, > especially when adding new machines to the cluster, or some machines' address > changed due to some reason. All clients need to update their host mapping > files. > The issue is to address this problem above, and try to add an option to let > each regionserver record themself by ip address, instead of hostname only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[ https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112121#comment-16112121 ] Cheney Sun commented on HBASE-11768: @stack, I found that you rebased the patch to master. Is the patch still on the roadmap? If so, I would like to fix the issues found by QA bot. > Register region server in zookeeper by ip address > - > > Key: HBASE-11768 > URL: https://issues.apache.org/jira/browse/HBASE-11768 > Project: HBase > Issue Type: Improvement > Components: regionserver >Affects Versions: 2.0.0 >Reporter: Cheney Sun > Labels: patch > Fix For: 2.0.0 > > Attachments: HBASE-11768.master.001.patch, HBASE_11768.patch > > > HBase cluster isn't always setup along with a DNS server. But regionservers > now register their hostnames in zookeeper, which bring some inconvenience > when regionserver isn't in one DNS server. In such situation, clients have to > maintain the ip/hostname mapping in their /etc/hosts files in order to > resolve the hostname returned from zookeeper to the right address. > However, this causes a lot of pain for clients to maintain the mapping, > especially when adding new machines to the cluster, or some machines' address > changed due to some reason. All clients need to update their host mapping > files. > The issue is to address this problem above, and try to add an option to let > each regionserver record themself by ip address, instead of hostname only. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-14618) Procedure V2: Implement move shell command to use Proc-V2 assignment
[ https://issues.apache.org/jira/browse/HBASE-14618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-14618. --- Resolution: Not A Problem This is done, right [~syuanjiang]? The move.rb calls Admin#move which internally talks to the master which does a pv2 move. Reopen if I misunderstood sir. > Procedure V2: Implement move shell command to use Proc-V2 assignment > > > Key: HBASE-14618 > URL: https://issues.apache.org/jira/browse/HBASE-14618 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18497) Add clock type to proto message for HLC region open/close
[ https://issues.apache.org/jira/browse/HBASE-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18497: --- Attachment: HBASE-18497.HBASE-14070.HLC.001.patch > Add clock type to proto message for HLC region open/close > - > > Key: HBASE-18497 > URL: https://issues.apache.org/jira/browse/HBASE-18497 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18497.HBASE-14070.HLC.001.patch, > HBASE-18497.HBASE-14070.HLC.002.patch > > > This task covers the work for adding clock type to the protobuf message > NodeTime used for sending timestamps of each clock during region open and > close requests/responses. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[ https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-18108: -- Priority: Blocker (was: Critical) > Procedure WALs are archived but not cleaned; fix > > > Key: HBASE-18108 > URL: https://issues.apache.org/jira/browse/HBASE-18108 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Priority: Blocker > Fix For: 2.0.0 > > > The Procedure WAL files used to be deleted when done. HBASE-14614 keeps them > around in case issue but what is missing is a GC for no-longer-needed WAL > files. This one is pretty important. > From WALProcedureStore Cleaner TODO in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.r2pc835nb7vi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17049) Find out why AsyncFSWAL issues much more syncs than FSHLog
[ https://issues.apache.org/jira/browse/HBASE-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17049: -- Priority: Blocker (was: Critical) > Find out why AsyncFSWAL issues much more syncs than FSHLog > -- > > Key: HBASE-17049 > URL: https://issues.apache.org/jira/browse/HBASE-17049 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Priority: Blocker > Fix For: 2.0.0 > > Attachments: delay-sync.patch > > > https://issues.apache.org/jira/browse/HBASE-16890?focusedCommentId=15647590=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15647590 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16550) Procedure v2 - Add AM compatibility for 2.x Master and 1.x RSs; i.e. support Rolling Upgrade from hbase-1 to -2.
[ https://issues.apache.org/jira/browse/HBASE-16550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-16550: -- Priority: Blocker (was: Critical) > Procedure v2 - Add AM compatibility for 2.x Master and 1.x RSs; i.e. support > Rolling Upgrade from hbase-1 to -2. > > > Key: HBASE-16550 > URL: https://issues.apache.org/jira/browse/HBASE-16550 > Project: HBase > Issue Type: Sub-task > Components: proc-v2, Region Assignment >Affects Versions: 2.0.0 >Reporter: Matteo Bertozzi >Assignee: Matteo Bertozzi >Priority: Blocker > Fix For: 2.0.0 > > > Core AM HBASE-14614 relies on the RS to be using zkless assignment. Add > support for the old a plain non zkless AM -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15547) Balancer should take into account number of PENDING_OPEN regions
[ https://issues.apache.org/jira/browse/HBASE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112092#comment-16112092 ] stack commented on HBASE-15547: --- Removing 2.0.0. Assign is different in 2.0.0. No PENDING_OPEN state for instance. > Balancer should take into account number of PENDING_OPEN regions > > > Key: HBASE-15547 > URL: https://issues.apache.org/jira/browse/HBASE-15547 > Project: HBase > Issue Type: Improvement > Components: Balancer, Operability, Region Assignment >Affects Versions: 0.98.0, 1.0.0 >Reporter: Sean Busbey >Priority: Critical > Fix For: 1.5.0 > > > We recently had a cluster get into a bad state where a subset of region > servers consistently could not open new regions (but could continue serving > the regions they already hosted). > Recovering the cluster was just a matter of restarting region servers in > sequence. However, this led to things getting substantially worse before they > got better since the bulk assigner continued to place an uniform number of > recovered regions across all servers, including onto those that could not > open regions. > It would be useful if the balancer could penalize regionservers with a > backlog of pending_open regions and place more work on those regionservers > that are properly serving. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15547) Balancer should take into account number of PENDING_OPEN regions
[ https://issues.apache.org/jira/browse/HBASE-15547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15547: -- Fix Version/s: (was: 2.0.0) > Balancer should take into account number of PENDING_OPEN regions > > > Key: HBASE-15547 > URL: https://issues.apache.org/jira/browse/HBASE-15547 > Project: HBase > Issue Type: Improvement > Components: Balancer, Operability, Region Assignment >Affects Versions: 0.98.0, 1.0.0 >Reporter: Sean Busbey >Priority: Critical > Fix For: 1.5.0 > > > We recently had a cluster get into a bad state where a subset of region > servers consistently could not open new regions (but could continue serving > the regions they already hosted). > Recovering the cluster was just a matter of restarting region servers in > sequence. However, this led to things getting substantially worse before they > got better since the bulk assigner continued to place an uniform number of > recovered regions across all servers, including onto those that could not > open regions. > It would be useful if the balancer could penalize regionservers with a > backlog of pending_open regions and place more work on those regionservers > that are properly serving. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-14506) Reenable TestDistributedLogSplitting#testWorkerAbort
[ https://issues.apache.org/jira/browse/HBASE-14506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-14506. --- Resolution: Won't Fix Won't fix. Dodgy test. > Reenable TestDistributedLogSplitting#testWorkerAbort > > > Key: HBASE-14506 > URL: https://issues.apache.org/jira/browse/HBASE-14506 > Project: HBase > Issue Type: Bug > Components: test >Reporter: stack >Priority: Critical > Fix For: 2.0.0, 1.3.2 > > Attachments: > org.apache.hadoop.hbase.master.TestDistributedLogSplitting-output.txt > > > See attached log. Flakey up on jenkins and down locally. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14619) Procedure V2: Implement balancer to be Procedure-based
[ https://issues.apache.org/jira/browse/HBASE-14619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112086#comment-16112086 ] stack commented on HBASE-14619: --- Moved to be standalone issue. Needs bit of scoping on what is meant here. Thanks. > Procedure V2: Implement balancer to be Procedure-based > -- > > Key: HBASE-14619 > URL: https://issues.apache.org/jira/browse/HBASE-14619 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14619) Procedure V2: Implement balancer to be Procedure-based
[ https://issues.apache.org/jira/browse/HBASE-14619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14619: -- Issue Type: Bug (was: Sub-task) Parent: (was: HBASE-14350) > Procedure V2: Implement balancer to be Procedure-based > -- > > Key: HBASE-14619 > URL: https://issues.apache.org/jira/browse/HBASE-14619 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Stephen Yuan Jiang >Assignee: Stephen Yuan Jiang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18507) [C++] Support for MultiPuts in AsyncBatchRpcRetryingCaller class
[
https://issues.apache.org/jira/browse/HBASE-18507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112083#comment-16112083
]
Enis Soztutar commented on HBASE-18507:
---
Thanks Sudeep for the patch.
- Since you are doing templating for the response, would it be cleaner to do
templating for the Get / Put as well. Within a batch, it will never be more
than 1 type of requests, so maybe we can see whether that is better than doing
{{shared_ptr}}. If not, we can stick with {{shared_ptr}}.
- You should use std::make_shared<>() instead.
{code}
+ Row *rowp = new hbase::Put(put);
{code}
- This is not needed:
{code}
+ std::vector results{};
{code}
- If we can do this logic with the templates, I think it will be better:
{code}
+ auto getp = dynamic_cast(pget.get());
+ if (getp == nullptr) {
+auto putp = dynamic_cast(pget.get());
+if (putp == nullptr) {
+ //TODO throw exception ???
+ LOG(ERROR)<< "This is not Get/Put";
+} else {
+
pb_action->set_allocated_mutation(RequestConverter::ToMutation(MutationType::MutationProto_MutationType_PUT,
*putp, -1).release());
+ pb_action->set_index(action_num);
+}
+ } else {
+pb_action->set_allocated_get(RequestConverter::ToGet(*getp).release());
+pb_action->set_index(action_num);
+ }
{code}
If not, instead you should use {{typeid}} to check the type, instead of using
dynamic_cast directly.
> [C++] Support for MultiPuts in AsyncBatchRpcRetryingCaller class
>
>
> Key: HBASE-18507
> URL: https://issues.apache.org/jira/browse/HBASE-18507
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sudeep Sunthankar
>Assignee: Sudeep Sunthankar
> Attachments: HBASE-18507.HBASE-14850.v1.patch
>
>
> We will be addressing Multi Puts changes to AsyncBatchRpcRetryingCaller class
> here
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14756) Break out ClientBackoffPolicy factors into configurable and stackable components
[
https://issues.apache.org/jira/browse/HBASE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112080#comment-16112080
]
Hadoop QA commented on HBASE-14756:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
32m 55s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
48s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 45m 30s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-14756 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12770606/HBASE-14756.patch |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 89a1160544e6 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 504a1f1 |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7906/testReport/ |
| modules | C: hbase-client U: hbase-client |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7906/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Break out ClientBackoffPolicy factors into configurable and stackable
> components
>
>
> Key: HBASE-14756
> URL: https://issues.apache.org/jira/browse/HBASE-14756
> Project: HBase
> Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Heng Chen
> Attachments: HBASE-14756.patch
>
>
> Currently
[jira] [Updated] (HBASE-18510) Update clock on replaying recovered edits
[ https://issues.apache.org/jira/browse/HBASE-18510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18510: --- Attachment: HBASE-18510.HBASE-14070.HLC.001.patch > Update clock on replaying recovered edits > - > > Key: HBASE-18510 > URL: https://issues.apache.org/jira/browse/HBASE-18510 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18510.HBASE-14070.HLC.001.patch > > > This task covers updating the clock on recovery in > HRegion#replayRecoveredEdits and includes region-level tests. > Credit for the baseline of this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-11768) Register region server in zookeeper by ip address
[
https://issues.apache.org/jira/browse/HBASE-11768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112075#comment-16112075
]
Hadoop QA commented on HBASE-11768:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
5s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
19s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
19s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 19s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 2 line(s) that end in whitespace. Use git
apply --whitespace=fix <>. Refer https://git-scm.com/docs/git-apply
{color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
39s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
2s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m
28s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
55s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
21s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m
45s{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m
10s{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.2. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 11m
35s{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 13m
0s{color} | {color:red} The patch causes 14 errors with Hadoop v3.0.0-alpha4.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
18s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
17s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
36s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color}
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112070#comment-16112070 ] Chia-Ping Tsai commented on HBASE-17056: There is a addendum [commit|https://github.com/apache/hbase/commit/6440509d7d28b0a0ecf027352d64605d7085ff29] which removes the redundant dependency for branch-2. Why not push similar fix for master? > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch, HBASE-17056.master.004.patch, > HBASE-17056.master.005.patch, HBASE-17056.master.006.patch, > HBASE-17056.master.006.patch, HBASE-17056.master.007.patch, > HBASE-17056.master.007.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[
https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112069#comment-16112069
]
Hadoop QA commented on HBASE-15321:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
37s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
31s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
23s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
23s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
48s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
25s{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m
42s{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.2. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
59s{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
21s{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
49s{color} | {color:red} The patch causes 16 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m
13s{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m
54s{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.2. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 11m
29s{color} | {color:red} The patch causes 16 errors with Hadoop v2.7.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 12m
56s{color} | {color:red} The patch causes 16 errors with Hadoop v3.0.0-alpha4.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
28s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
33s{color} | {color:red} hbase-server generated 1 new + 0 unchanged - 0 fixed =
1 total (was 0) {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 28s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 27m 56s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-15321 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790981/HBASE-15321-v4.patch |
|
[jira] [Commented] (HBASE-13581) Improve usability for storefile stats in web status pages
[ https://issues.apache.org/jira/browse/HBASE-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112068#comment-16112068 ] stack commented on HBASE-13581: --- Unscheduling a nice-to-have. We can bring it back if progress. Thanks. > Improve usability for storefile stats in web status pages > - > > Key: HBASE-13581 > URL: https://issues.apache.org/jira/browse/HBASE-13581 > Project: HBase > Issue Type: Improvement > Components: Operability >Affects Versions: 1.0.0 >Reporter: Sean Busbey >Assignee: Ashutosh Jindal >Priority: Minor > Labels: beginner > Attachments: HBASE-13581.patch, rs_in_master_status_page.tiff > > > Right now the "Storefiles" section of the Region Servers status shown in the > Master web ui is inconsistent in units (sometimes "m" and sometimes "mb") and > uses units that are fixed rather than adapting to the number being presented > (e.g. reporting a bloom filter size of 13540k instead of 13m). > Clean up to > * consistently use correct units (i.e. KiB, MiB, GiB since that's what we're > measuring) > * adapt the units used so that we use the biggest ones -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14220) test-patch.sh should verify src tgz generates and builds correctly
[ https://issues.apache.org/jira/browse/HBASE-14220?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112067#comment-16112067 ] stack commented on HBASE-14220: --- Looks like a good start to me [~busbey] +1 > test-patch.sh should verify src tgz generates and builds correctly > -- > > Key: HBASE-14220 > URL: https://issues.apache.org/jira/browse/HBASE-14220 > Project: HBase > Issue Type: Task > Components: build >Reporter: Nick Dimiduk >Assignee: Sean Busbey >Priority: Minor > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14220.0.patch > > > Twice at release time I've bumped into broken src tgz packaging. This is > somewhat expected as builds tend to have dark, hidden corners. Let's add a > check to our build bot so we find these issues earlier. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-13581) Improve usability for storefile stats in web status pages
[ https://issues.apache.org/jira/browse/HBASE-13581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-13581: -- Fix Version/s: (was: 2.0.0) > Improve usability for storefile stats in web status pages > - > > Key: HBASE-13581 > URL: https://issues.apache.org/jira/browse/HBASE-13581 > Project: HBase > Issue Type: Improvement > Components: Operability >Affects Versions: 1.0.0 >Reporter: Sean Busbey >Assignee: Ashutosh Jindal >Priority: Minor > Labels: beginner > Attachments: HBASE-13581.patch, rs_in_master_status_page.tiff > > > Right now the "Storefiles" section of the Region Servers status shown in the > Master web ui is inconsistent in units (sometimes "m" and sometimes "mb") and > uses units that are fixed rather than adapting to the number being presented > (e.g. reporting a bloom filter size of 13540k instead of 13m). > Clean up to > * consistently use correct units (i.e. KiB, MiB, GiB since that's what we're > measuring) > * adapt the units used so that we use the biggest ones -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15042) refactor so that site materials are in the Standard Maven Place
[
https://issues.apache.org/jira/browse/HBASE-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112064#comment-16112064
]
stack commented on HBASE-15042:
---
+1 on patch. Works nicely. Asking [~misty] what needs to be edited in our
site-publishing before pushing this... Thanks [~Jan Hentschel]
> refactor so that site materials are in the Standard Maven Place
> ---
>
> Key: HBASE-15042
> URL: https://issues.apache.org/jira/browse/HBASE-15042
> Project: HBase
> Issue Type: Task
> Components: build, website
>Reporter: Sean Busbey
>Assignee: Jan Hentschel
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15042.master.001.patch,
> HBASE-15042.master.002.patch, HBASE-15042.master.002.patch,
> HBASE-15042.master.003.patch
>
>
> for some reason we currently have our site materials in {{src/main/site}}
> rather than the maven prescribed {{src/site}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18497) Add clock type to proto message for HLC region open/close
[ https://issues.apache.org/jira/browse/HBASE-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18497: - Status: Patch Available (was: Open) > Add clock type to proto message for HLC region open/close > - > > Key: HBASE-18497 > URL: https://issues.apache.org/jira/browse/HBASE-18497 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18497.HBASE-14070.HLC.002.patch > > > This task covers the work for adding clock type to the protobuf message > NodeTime used for sending timestamps of each clock during region open and > close requests/responses. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17165) Add retry to LoadIncrementalHFiles tool
[ https://issues.apache.org/jira/browse/HBASE-17165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112059#comment-16112059 ] stack commented on HBASE-17165: --- [~itsgrimetime] Hey boss. Any idea why the branch-1 and master patches differ sir? ([~zyork]). Thanks sir. Would like to push same thing on both branches. > Add retry to LoadIncrementalHFiles tool > --- > > Key: HBASE-17165 > URL: https://issues.apache.org/jira/browse/HBASE-17165 > Project: HBase > Issue Type: Improvement > Components: hbase, HFile, tooling >Affects Versions: 2.0.0, 1.2.3 >Reporter: Mike Grimes >Assignee: Mike Grimes >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-17165.branch-1.001.patch, > HBASE-17165.branch-1.001.patch, HBASE-17165.branch-1.2.001.patch, > HBASE-17165.branch-1.2.002.patch, HBASE-17165.branch-1.2.003.patch, > HBASE-17165.branch-1.2.004.patch, HBASE-17165.master.001.patch, > HBASE-17165.master.002.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > As using the LoadIncrementalHFiles tool with S3 as the filesystem is prone to > failing due to FileNotFoundExceptions due to inconsistency, simple, > configurable retry logic was added. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18102) [SHELL] Purge close_region command that allows by-pass of Master
[
https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112056#comment-16112056
]
Hadoop QA commented on HBASE-18102:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
41s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
5s{color} | {color:red} The patch generated 2 new + 345 unchanged - 4 fixed =
347 total (was 349) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
12s{color} | {color:red} The patch generated 2 new + 511 unchanged - 0 fixed =
513 total (was 511) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 40s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
52s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 36m 11s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:bdc94b1 |
| JIRA Issue | HBASE-18102 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880141/HBASE-18102.master.002.patch
|
| Optional Tests | asflicense unit rubocop ruby_lint |
| uname | Linux 9c19d94ca98a 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 71151eb |
| rubocop | v0.49.1 |
| rubocop |
https://builds.apache.org/job/PreCommit-HBASE-Build/7892/artifact/patchprocess/diff-patch-rubocop.txt
|
| ruby-lint | v2.3.1 |
| ruby-lint |
https://builds.apache.org/job/PreCommit-HBASE-Build/7892/artifact/patchprocess/diff-patch-ruby-lint.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7892/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7892/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> [SHELL] Purge close_region command that allows by-pass of Master
>
>
> Key: HBASE-18102
> URL: https://issues.apache.org/jira/browse/HBASE-18102
> Project: HBase
> Issue Type: Sub-task
> Components: Operability, shell
>Reporter: stack
>Assignee: Appy
> Fix For: 2.0.0, 3.0.0
>
> Attachments: HBASE-18102.master.001.patch,
> HBASE-18102.master.002.patch
>
>
> In AMv2, if a RS is not aligned with Master notions of how the world is, then
> the Master will kill the deviant RS (TODO: is forcing compliance via less
> radical means -- but that is how it is currently).
> The shell currently allows by-passing the Master to make cluster
> modifications such as our being able to send a close directly to a
> RegionServer for it to execute locally. This facility was used in the past to
> do fix-up when Master lost account of Region locations. In the new regime,
> such mis-accounting should no longer happen and, should a user mistakenly do
> an explicit close against a RS, the consequences will be more than the user
> bargained for; the Master will shut down the RS as soon as it reports close
> of a Region the master thinks should be open (No independence allowed!).
> This issue is to review shell Region and Table manipulation commands to purge
> those that by-pass Master or at least to add big warning.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17706) TableSkewCostFunction improperly computes max skew
[ https://issues.apache.org/jira/browse/HBASE-17706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17706: -- Priority: Major (was: Minor) > TableSkewCostFunction improperly computes max skew > -- > > Key: HBASE-17706 > URL: https://issues.apache.org/jira/browse/HBASE-17706 > Project: HBase > Issue Type: Bug > Components: Balancer >Affects Versions: 1.2.0 > Environment: CentOS Derivative with a derivative of the 3.18.43 > kernel. HBase on CDH5.9.0 with some patches. HDFS CDH 5.9.0 with no patches. >Reporter: Kahlil Oppenheimer >Assignee: Kahlil Oppenheimer > Labels: patch > Fix For: 2.0.0 > > Attachments: HBASE-17706-01.patch, HBASE-17706-02.patch, > HBASE-17706-03.patch, HBASE-17706-04.patch, HBASE-17706-05.patch, > HBASE-17706-06.patch, HBASE-17706-07.patch, HBASE-17706.patch > > > We noticed while running unit tests that the TableSkewCostFunction computed > cost did not change as the balancer ran and simulated moves across the > cluster. After investigating, we found that this happened in particular when > the cluster started out with at least one table very strongly skewed. > We noticed that the TableSkewCostFunction depends on a field of the > BaseLoadBalancer.Cluster class called numMaxRegionsPerTable, but this field > is not properly maintained as regionMoves are simulated for the cluster. The > field only ever increases as the maximum number of regions per table > increases, but it does not decrease as the maximum number per table goes down. > This patch corrects that behavior so that the field is accurately maintained, > and thus the TableSkewCostFunction produces a more correct value as the > balancer runs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-13652) Case-insensitivity of file system affects table creation
[
https://issues.apache.org/jira/browse/HBASE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112048#comment-16112048
]
Hadoop QA commented on HBASE-13652:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-13652 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-13652 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12847525/HBASE-13652.master.005.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7898/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Case-insensitivity of file system affects table creation
>
>
> Key: HBASE-13652
> URL: https://issues.apache.org/jira/browse/HBASE-13652
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.0.0
> Environment: HBase standalone mode on Mac OS X.
>Reporter: Lars George
>Assignee: Xuesen Liang
> Labels: beginner
> Attachments: HBASE-13652.master.001.patch,
> HBASE-13652.master.002.patch, HBASE-13652.master.003.patch,
> HBASE-13652.master.004.patch, HBASE-13652.master.005.patch
>
>
> I noticed this on my Mac OS machine:
> {noformat}
> hbase(main):003:0> list
> TABLE
>
>
> 0 row(s) in 0.0260 seconds
> => []
> hbase(main):004:0> create 'TestTable', 'info'
> 0 row(s) in 0.2830 seconds
> => Hbase::Table - TestTable
> hbase(main):005:0> create 'testtable', 'colfam1'
> 0 row(s) in 0.1750 seconds
> => Hbase::Table - testtable
> hbase(main):006:0> list
> TABLE
>
>
> TestTable
>
>
> TestTable
>
>
> 2 row(s) in 0.0170 seconds
> => ["TestTable", "TestTable"]
> hbase(main):007:0> status 'detailed'
> version 1.0.0
> 0 regionsInTransition
> master coprocessors: []
> 1 live servers
> de1-app-mba-1.internal.larsgeorge.com:58824 1431124680152
> requestsPerSecond=0.0, numberOfOnlineRegions=4, usedHeapMB=47,
> maxHeapMB=4062, numberOfStores=4, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=16, writeRequestsCount=8,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> coprocessors=[]
> "TestTable,,1431124762491.cb30b003b192aa1d429e5a8e908a2f7d."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:meta,,1"
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=10, writeRequestsCount=6,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:namespace,,1431124686536.42728f3a3411b0d8ff21c7a2622d9378."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "testtable,,1431124773352.8d461d5069d1c88bc3b26562ab30e333."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0,
[jira] [Commented] (HBASE-18303) Clean up some parameterized test declarations
[ https://issues.apache.org/jira/browse/HBASE-18303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112053#comment-16112053 ] stack commented on HBASE-18303: --- Skimmed. Looks good. > Clean up some parameterized test declarations > - > > Key: HBASE-18303 > URL: https://issues.apache.org/jira/browse/HBASE-18303 > Project: HBase > Issue Type: Improvement > Components: test >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Minor > Fix For: 2.0.0 > > Attachments: HBASE-18303.patch, HBASE-18303.patch > > > While debugging something unrelated, I noticed that we use the constructor > form of junit parameterized tests, instead of the annotated members form. > I personally find using the @Parameter annotation more clear. > Also, we can move the parameter generator to hbase-common so that it is > accessible in more modules. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18492) [AMv2] Embed code for selecting highest versioned region server for system table regions in AssignmentManager.processAssignQueue()
[
https://issues.apache.org/jira/browse/HBASE-18492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112049#comment-16112049
]
Hadoop QA commented on HBASE-18492:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-18492 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18492 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12880124/hbase-18492.master.002.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7904/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> [AMv2] Embed code for selecting highest versioned region server for system
> table regions in AssignmentManager.processAssignQueue()
> --
>
> Key: HBASE-18492
> URL: https://issues.apache.org/jira/browse/HBASE-18492
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0
>
> Attachments: hbase-18492.master.001.patch,
> hbase-18492.master.002.patch
>
>
> Embed logic of selecting highest versioned region server for system table
> regions in AssignmentManager.processAssignQueue(). This way from any section
> of the code when system table regions are re/assigned, only highest versioned
> RS are candidates for target servers.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12333) Add Integration Test Runner which is more friendly
[
https://issues.apache.org/jira/browse/HBASE-12333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112052#comment-16112052
]
Hadoop QA commented on HBASE-12333:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-12333 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-12333 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12690469/HBASE-12333-v3.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7905/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Add Integration Test Runner which is more friendly
> --
>
> Key: HBASE-12333
> URL: https://issues.apache.org/jira/browse/HBASE-12333
> Project: HBase
> Issue Type: New Feature
> Components: test
>Affects Versions: 2.0.0
>Reporter: Manukranth Kolloju
>Assignee: Manukranth Kolloju
> Attachments:
> 0001-HBASE-12333-Add-Integration-Test-Runner-which-is-mor.patch,
> HBASE-12333-v2.patch, HBASE-12333-v3.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> This Jira is intended to add a Driver class which would run a list of
> Integration tests on an actual hbase cluster. And generate a machine readable
> results file in JSON and put it on HDFS. The idea is to make it easy to run
> driver class using a long list of appropriate command line params and wait
> for the JSON file on the HDFS. This will help in plugging into external
> automation and makes it easier to maintain Continuous Integration Scripts.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112051#comment-16112051
]
Dave Latham commented on HBASE-14247:
-
I'd be concerned about first introducing a regression with this issue, and only
then addressing it if there's anyone paying enough attention to do so. I think
it would be better to first ensure the log cleaner will handle multiple
directories in a single batch, then change the log layout to be multiple
directories.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12636) Avoid too many write operations on zookeeper in replication
[
https://issues.apache.org/jira/browse/HBASE-12636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112050#comment-16112050
]
Hadoop QA commented on HBASE-12636:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m
4s{color} | {color:blue} The patch file was not named according to hbase's
naming conventions. Please see
https://yetus.apache.org/documentation/0.4.0/precommit-patchnames for
instructions. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-12636 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-12636 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12685233/HBASE-12635-v2.diff |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7903/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Avoid too many write operations on zookeeper in replication
> ---
>
> Key: HBASE-12636
> URL: https://issues.apache.org/jira/browse/HBASE-12636
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 0.94.11
>Reporter: Liu Shaohui
>Assignee: Liu Shaohui
> Labels: replication
> Attachments: HBASE-12635-v2.diff, HBASE-12636-v1.diff
>
>
> In our production cluster, we found there are about over 1k write operations
> per second on zookeeper from hbase replication. The reason is that the
> replication source will write the log position to zookeeper for every edit
> shipping. If the current replicating WAL is just the WAL that regionserver is
> writing to, each skipping will be very small but the frequency is very high,
> which causes many write operations on zookeeper.
> A simple solution is that writing log position to zookeeper when position
> diff or skipped edit number is larger than a threshold, not every edit
> shipping.
> Suggestions are welcomed, thx~
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15069) Unify HFile Writer and Reader creation patterns
[
https://issues.apache.org/jira/browse/HBASE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112047#comment-16112047
]
Hadoop QA commented on HBASE-15069:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-15069 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-15069 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12782138/hbase-15069.v4b.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7897/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Unify HFile Writer and Reader creation patterns
> ---
>
> Key: HBASE-15069
> URL: https://issues.apache.org/jira/browse/HBASE-15069
> Project: HBase
> Issue Type: Bug
> Components: HFile
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-15069.patch, hbase-15069.v2.patch,
> hbase-15069.v3.patch, hbase-15069.v4b.patch, hbase-15069.v4.patch
>
>
> There are a plethora of different static methods sprinkled through out
> HStoreFile and HFile, and many tests that have extraneous calls to 'new
> CacheConfig(conf)' or essentially extraneous FileSystem arguments threaded
> through out the code.
> This patch forces all creation to go through HFile Reader and Writer
> Builders, eliminates all static Builder constructors, and limits the exposure
> Reader/Writers . It also forces all HFile writer uses outside of the
> o.a.h.h.io.hfile package to use the StoreFile writers
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15061) Refactor StoreFileScanner creation to builder pattern
[
https://issues.apache.org/jira/browse/HBASE-15061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112044#comment-16112044
]
Hadoop QA commented on HBASE-15061:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-15061 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-15061 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12780058/hbase-15061.v2.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7900/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Refactor StoreFileScanner creation to builder pattern
> -
>
> Key: HBASE-15061
> URL: https://issues.apache.org/jira/browse/HBASE-15061
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-15061.patch, hbase-15061.v2.patch
>
>
> There are several falvors of calls that creates a list of StoreFileScanners,
> and new feature have been added to this recently. This patch converts the
> somewhat difficult to read (need to go to javadoc) call:
> {code}
> // which args are the most relevant to this?
> - List sfScanners =
> StoreFileScanner.getScannersForStoreFiles(sfs,
> -cacheMobBlocks, true, false, false, readPt);
> {code}
> into one that is more literate:
> {code}
> // ah, very clearly we are using defaults except for the caching settings
> + List sfScanners = new
> StoreFileScanner.ListBuilder(sfs, readPt)
> + .withCacheBlocks(cacheMobBlocks).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14272) Enforce major compaction on stores with TTL or time.to.purge.deletes enabled
[
https://issues.apache.org/jira/browse/HBASE-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112045#comment-16112045
]
Hadoop QA commented on HBASE-14272:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-14272 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-14272 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12754114/HBASE-14272-v2.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7901/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Enforce major compaction on stores with TTL or time.to.purge.deletes enabled
>
>
> Key: HBASE-14272
> URL: https://issues.apache.org/jira/browse/HBASE-14272
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Lars Hofhansl
> Attachments: HBASE-14272.patch, HBASE-14272-v2.patch
>
>
> Currently, if store has one (major compacted) file, the only case when major
> compaction will be triggered for this file again - when locality is below
> threshold, defined by *hbase.hstore.min.locality.to.skip.major.compact* or
> TTL expired some cells. If file has locality greater than this threshold it
> will never be major compacted until Store's TTL kicks in. For CF with
> KEEP_DELETED_CELLS on, compaction must be enabled always (even for single
> file), regardless of locality, when deleted cells are expired
> (*hbase.hstore.time.to.purge.deletes*)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-7108) Don't use legal family name for system folder at region level
[
https://issues.apache.org/jira/browse/HBASE-7108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112042#comment-16112042
]
Hadoop QA commented on HBASE-7108:
--
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 6s{color}
| {color:red} HBASE-7108 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-7108 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12552359/HBASE-7108-v0.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7894/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Don't use legal family name for system folder at region level
> -
>
> Key: HBASE-7108
> URL: https://issues.apache.org/jira/browse/HBASE-7108
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Affects Versions: 0.92.2, 0.94.2, 0.95.2
>Reporter: Matteo Bertozzi
>Assignee: Matteo Bertozzi
>Priority: Minor
> Attachments: HBASE-7108-v0.patch
>
>
> CHANGED, was: Don't allow "recovered.edits" as legal family name
> Region directories can contain folders called "recovered.edits", log
> splitting related.
> But there's nothing that prevent a user to create a family with that name...
> HLog.RECOVERED_EDITS_DIR = "recovered.edits";
> HRegion.MERGEDIR = "merges"; // fixed with HBASE-6158
> SplitTransaction.SPLITDIR = "splits"; // fixed with HBASE-6158
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-11467) New impl of Registry interface not using ZK + new RPCs on master protocol
[
https://issues.apache.org/jira/browse/HBASE-11467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112043#comment-16112043
]
Hadoop QA commented on HBASE-11467:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 9s{color}
| {color:red} HBASE-11467 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-11467 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12661351/HBASE-11467.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7896/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> New impl of Registry interface not using ZK + new RPCs on master protocol
> -
>
> Key: HBASE-11467
> URL: https://issues.apache.org/jira/browse/HBASE-11467
> Project: HBase
> Issue Type: Sub-task
> Components: Client, Consensus, Zookeeper
>Affects Versions: 2.0.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Attachments: HBASE-11467.patch, HBASE-11467.patch, HBASE-11467.patch
>
>
> Currently there' only one implementation of Registry interface, which is
> using ZK to get info about meta. Need to create implementation which will be
> using RPC calls to master the client is connected to.
> Review of early version of patch is here: https://reviews.apache.org/r/24296/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17104) Improve cryptic error message "Memstore size is" on region close
[
https://issues.apache.org/jira/browse/HBASE-17104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-17104:
--
Attachment: HBASE-17104.master.001 (1) (1).patch
Retry
> Improve cryptic error message "Memstore size is" on region close
>
>
> Key: HBASE-17104
> URL: https://issues.apache.org/jira/browse/HBASE-17104
> Project: HBase
> Issue Type: Bug
> Components: regionserver
>Reporter: Matteo Bertozzi
>Assignee: Sahil Aggarwal
>Priority: Trivial
> Labels: beginner, noob
> Fix For: 2.0.0
>
> Attachments: HBASE-17104.master.001 (1) (1).patch,
> HBASE-17104.master.001 (1).patch, HBASE-17104.master.001.patch
>
>
> while grepping my RS log for ERROR I found a cryptic
> {noformat}
> ERROR [RS_CLOSE_REGION-u1604vm:35021-1] regionserver.HRegion(1601): Memstore
> size is 33744
> {noformat}
> from the code looks like we seems to want to notify the user about the fact
> that on close the rs was not able to flush and there were things in the RS.
> https://github.com/apache/hbase/blob/c3685760f004450667920144f926383eb307de53/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java#L1601
> {code}
> if (!canFlush) {
> this.decrMemstoreSize(new MemstoreSize(memstoreDataSize.get(),
> getMemstoreHeapOverhead()));
> } else if (memstoreDataSize.get() != 0) {
> LOG.error("Memstore size is " + memstoreDataSize.get());
> }
> {code}
> this should probably not even be an error but a warn or even info, unless we
> have puts that specifically asked to not be written to the wal, otherwise
> the data in the memstore should be safe in the wals.
> In any case it will be nice to have a message describing what is going on and
> why we are notifying about the memstore size.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18298) RegionServerServices Interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112031#comment-16112031 ] stack commented on HBASE-18298: --- I did some review up in CP. Whats this issue about though Anoop? I'm not sure sir. I think I know but not clean on motive. Thanks. > RegionServerServices Interface cleanup for CP expose > > > Key: HBASE-18298 > URL: https://issues.apache.org/jira/browse/HBASE-18298 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-18298.patch, HBASE-18298_V2.patch, > HBASE-18298_V3.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112028#comment-16112028
]
Guanghao Zhang commented on HBASE-14247:
[~davelatham] Because the max-directory-items limit of HDFS, I thought the
first thing is make the old WAL directory scalable. Then if the cleaner has
performance problem, we can try to make it fast. Your concern can be addressed
after we resolve this issue? Thanks.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18248) Warn if monitored RPC task has been tied up beyond a configurable threshold
[ https://issues.apache.org/jira/browse/HBASE-18248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112024#comment-16112024 ] stack commented on HBASE-18248: --- [~apurtell] Looks good. You have to start a thread to monitor? There is no other thread running that could do this? What you see when stuck rpc? [~allan163] Any more comments sir? > Warn if monitored RPC task has been tied up beyond a configurable threshold > --- > > Key: HBASE-18248 > URL: https://issues.apache.org/jira/browse/HBASE-18248 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Andrew Purtell > Fix For: 2.0.0, 3.0.0, 1.4.0 > > Attachments: HBASE-18248-branch-1.patch, HBASE-18248-branch-1.patch, > HBASE-18248.patch, HBASE-18248.patch > > > Warn if monitored task has been tied up beyond a configurable threshold. We > especially want to do this for RPC tasks. Use a separate threshold for > warning about stuck RPC tasks versus other types of tasks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18102) [SHELL] Purge close_region command that allows by-pass of Master
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18102: - Resolution: Fixed Status: Resolved (was: Patch Available) > [SHELL] Purge close_region command that allows by-pass of Master > > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack >Assignee: Appy > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-18102.master.001.patch, > HBASE-18102.master.002.patch > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18102) [SHELL] Purge close_region command that allows by-pass of Master
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112021#comment-16112021 ] Appy commented on HBASE-18102: -- TestShell is in [flaky excludes list|https://builds.apache.org/job/HBase-Find-Flaky-Tests/lastSuccessfulBuild/artifact/excludes/*view*/], so it won't run as part of precommit. I ran the test locally with this patch on top of master and it passed, so pushing to fix broken tests > [SHELL] Purge close_region command that allows by-pass of Master > > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack >Assignee: Appy > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-18102.master.001.patch, > HBASE-18102.master.002.patch > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18485) Performance issue: ClientAsyncPrefetchScanner is slower than ClientSimpleScanner
[
https://issues.apache.org/jira/browse/HBASE-18485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Guanghao Zhang updated HBASE-18485:
---
Attachment: HBASE-18485-v4.patch
> Performance issue: ClientAsyncPrefetchScanner is slower than
> ClientSimpleScanner
>
>
> Key: HBASE-18485
> URL: https://issues.apache.org/jira/browse/HBASE-18485
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
> Attachments: HBASE-18485-v1.patch, HBASE-18485-v2.patch,
> HBASE-18485-v3.patch, HBASE-18485-v4.patch
>
>
> Copied the test result from HBASE-17994.
> {code}
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10
> --nomapred scan 1
> ./bin/hbase org.apache.hadoop.hbase.PerformanceEvaluation --rows=10
> --nomapred --asyncPrefetch=True scan 1
> {code}
> Mean latency.
> || ||Test1|| Test2 || Test3 || Test4|| Test5||
> |scan| 12.21 | 14.32 | 13.25 | 13.07 | 11.83 |
> |scan with prefetch=True | 37.36 | 37.88 | 37.56 | 37.66 | 38.28 |
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18020) Update API Compliance Checker to Incorporate Improvements Done in Hadoop
[ https://issues.apache.org/jira/browse/HBASE-18020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112018#comment-16112018 ] stack commented on HBASE-18020: --- [~dimaspivak] You have a chance to take a look see at [~awleblang]'s beautiful work? > Update API Compliance Checker to Incorporate Improvements Done in Hadoop > > > Key: HBASE-18020 > URL: https://issues.apache.org/jira/browse/HBASE-18020 > Project: HBase > Issue Type: Improvement > Components: API, community >Reporter: Alex Leblang >Assignee: Alex Leblang > Fix For: 2.0.0 > > Attachments: HBASE-18020.0.patch, HBASE-18020.branch-1.2.001.patch, > HBASE-18020.branch-1.2.002.patch, HBASE-18020.branch-1.2.003.patch, > HBASE-18020.branch-1.2.004.patch > > > Recently the Hadoop community has made a number of improvements in their api > compliance checker based on feedback from the hbase and kudu community. We > should adopt these changes ourselves. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18102) [SHELL] Purge close_region command that allows by-pass of Master
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112016#comment-16112016 ] Appy commented on HBASE-18102: -- Attached addendum fixing shell test. > [SHELL] Purge close_region command that allows by-pass of Master > > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack >Assignee: Appy > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-18102.master.001.patch, > HBASE-18102.master.002.patch > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18102) [SHELL] Purge close_region command that allows by-pass of Master
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18102: - Attachment: HBASE-18102.master.002.patch > [SHELL] Purge close_region command that allows by-pass of Master > > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack >Assignee: Appy > Fix For: 2.0.0, 3.0.0 > > Attachments: HBASE-18102.master.001.patch, > HBASE-18102.master.002.patch > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17079) HBase build fails on windows, hbase-archetype-builder is reason for failure
[
https://issues.apache.org/jira/browse/HBASE-17079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112013#comment-16112013
]
stack commented on HBASE-17079:
---
Unscheduling. Bring back in if starts to make progress again. This would be
nice to have.
> HBase build fails on windows, hbase-archetype-builder is reason for failure
> ---
>
> Key: HBASE-17079
> URL: https://issues.apache.org/jira/browse/HBASE-17079
> Project: HBase
> Issue Type: Bug
> Components: build
> Environment: windows
>Reporter: Mohammad Arshad
> Attachments: HBASE-17079.master.001.patch
>
>
> HBase buid fails on windows, hbase-archetype-builder is reason for failure.
> Cygwin is installed so the shell scripts should execute successfully.
> Here is build failure log
> {code}
> [INFO] Apache HBase - Archetype builder ... FAILURE [ 1.014
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 06:13 min
> [INFO] Finished at: 2016-11-12T18:12:26+05:30
> [INFO] Final Memory: 235M/1012M
> [INFO]
>
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.4.0:exec
> (make-scripts-executable) on project hbase-archetype-builder: Command
> execution failed. Process exited with an error: 1 (Exit value: 1) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :hbase-archetype-builder
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17079) HBase build fails on windows, hbase-archetype-builder is reason for failure
[
https://issues.apache.org/jira/browse/HBASE-17079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-17079:
--
Fix Version/s: (was: 2.0.0)
> HBase build fails on windows, hbase-archetype-builder is reason for failure
> ---
>
> Key: HBASE-17079
> URL: https://issues.apache.org/jira/browse/HBASE-17079
> Project: HBase
> Issue Type: Bug
> Components: build
> Environment: windows
>Reporter: Mohammad Arshad
> Attachments: HBASE-17079.master.001.patch
>
>
> HBase buid fails on windows, hbase-archetype-builder is reason for failure.
> Cygwin is installed so the shell scripts should execute successfully.
> Here is build failure log
> {code}
> [INFO] Apache HBase - Archetype builder ... FAILURE [ 1.014
> s]
> [INFO]
>
> [INFO] BUILD FAILURE
> [INFO]
>
> [INFO] Total time: 06:13 min
> [INFO] Finished at: 2016-11-12T18:12:26+05:30
> [INFO] Final Memory: 235M/1012M
> [INFO]
>
> [ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.4.0:exec
> (make-scripts-executable) on project hbase-archetype-builder: Command
> execution failed. Process exited with an error: 1 (Exit value: 1) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :hbase-archetype-builder
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112009#comment-16112009 ] stack commented on HBASE-15321: --- Unscheduling. Bring back in if starts to make progress again. This would be nice to have. > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Attachments: HBASE-15321.patch, HBASE-15321-v1.patch, > HBASE-15321-v2.patch, HBASE-15321-v3.patch, HBASE-15321-v4.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15321: -- Fix Version/s: (was: 2.0.0) > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Attachments: HBASE-15321.patch, HBASE-15321-v1.patch, > HBASE-15321-v2.patch, HBASE-15321-v3.patch, HBASE-15321-v4.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15069) Unify HFile Writer and Reader creation patterns
[ https://issues.apache.org/jira/browse/HBASE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112004#comment-16112004 ] stack commented on HBASE-15069: --- Unscheduling. Bring back in if starts to make progress again. This would be nice to have. > Unify HFile Writer and Reader creation patterns > --- > > Key: HBASE-15069 > URL: https://issues.apache.org/jira/browse/HBASE-15069 > Project: HBase > Issue Type: Bug > Components: HFile >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-15069.patch, hbase-15069.v2.patch, > hbase-15069.v3.patch, hbase-15069.v4b.patch, hbase-15069.v4.patch > > > There are a plethora of different static methods sprinkled through out > HStoreFile and HFile, and many tests that have extraneous calls to 'new > CacheConfig(conf)' or essentially extraneous FileSystem arguments threaded > through out the code. > This patch forces all creation to go through HFile Reader and Writer > Builders, eliminates all static Builder constructors, and limits the exposure > Reader/Writers . It also forces all HFile writer uses outside of the > o.a.h.h.io.hfile package to use the StoreFile writers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15069) Unify HFile Writer and Reader creation patterns
[ https://issues.apache.org/jira/browse/HBASE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15069: -- Fix Version/s: (was: 2.0.0) > Unify HFile Writer and Reader creation patterns > --- > > Key: HBASE-15069 > URL: https://issues.apache.org/jira/browse/HBASE-15069 > Project: HBase > Issue Type: Bug > Components: HFile >Affects Versions: 2.0.0 >Reporter: Jonathan Hsieh >Assignee: Jonathan Hsieh > Attachments: hbase-15069.patch, hbase-15069.v2.patch, > hbase-15069.v3.patch, hbase-15069.v4b.patch, hbase-15069.v4.patch > > > There are a plethora of different static methods sprinkled through out > HStoreFile and HFile, and many tests that have extraneous calls to 'new > CacheConfig(conf)' or essentially extraneous FileSystem arguments threaded > through out the code. > This patch forces all creation to go through HFile Reader and Writer > Builders, eliminates all static Builder constructors, and limits the exposure > Reader/Writers . It also forces all HFile writer uses outside of the > o.a.h.h.io.hfile package to use the StoreFile writers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15061) Refactor StoreFileScanner creation to builder pattern
[
https://issues.apache.org/jira/browse/HBASE-15061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16112001#comment-16112001
]
stack commented on HBASE-15061:
---
Unscheduling. No follow-up. Bring back in if starts to make progress.
> Refactor StoreFileScanner creation to builder pattern
> -
>
> Key: HBASE-15061
> URL: https://issues.apache.org/jira/browse/HBASE-15061
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-15061.patch, hbase-15061.v2.patch
>
>
> There are several falvors of calls that creates a list of StoreFileScanners,
> and new feature have been added to this recently. This patch converts the
> somewhat difficult to read (need to go to javadoc) call:
> {code}
> // which args are the most relevant to this?
> - List sfScanners =
> StoreFileScanner.getScannersForStoreFiles(sfs,
> -cacheMobBlocks, true, false, false, readPt);
> {code}
> into one that is more literate:
> {code}
> // ah, very clearly we are using defaults except for the caching settings
> + List sfScanners = new
> StoreFileScanner.ListBuilder(sfs, readPt)
> + .withCacheBlocks(cacheMobBlocks).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-15061) Refactor StoreFileScanner creation to builder pattern
[
https://issues.apache.org/jira/browse/HBASE-15061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-15061:
--
Fix Version/s: (was: 2.0.0)
> Refactor StoreFileScanner creation to builder pattern
> -
>
> Key: HBASE-15061
> URL: https://issues.apache.org/jira/browse/HBASE-15061
> Project: HBase
> Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Attachments: hbase-15061.patch, hbase-15061.v2.patch
>
>
> There are several falvors of calls that creates a list of StoreFileScanners,
> and new feature have been added to this recently. This patch converts the
> somewhat difficult to read (need to go to javadoc) call:
> {code}
> // which args are the most relevant to this?
> - List sfScanners =
> StoreFileScanner.getScannersForStoreFiles(sfs,
> -cacheMobBlocks, true, false, false, readPt);
> {code}
> into one that is more literate:
> {code}
> // ah, very clearly we are using defaults except for the caching settings
> + List sfScanners = new
> StoreFileScanner.ListBuilder(sfs, readPt)
> + .withCacheBlocks(cacheMobBlocks).build();
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18510) Update clock on replaying recovered edits
Amit Patel created HBASE-18510: -- Summary: Update clock on replaying recovered edits Key: HBASE-18510 URL: https://issues.apache.org/jira/browse/HBASE-18510 Project: HBase Issue Type: Sub-task Reporter: Amit Patel Assignee: Amit Patel Priority: Minor This task covers updating the clock on recovery in HRegion#replayRecoveredEdits and includes region-level tests. Credit for the baseline of this work all goes to our Sai Teja Ranuva. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18510) Update clock on replaying recovered edits
[ https://issues.apache.org/jira/browse/HBASE-18510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18510: --- Description: This task covers updating the clock on recovery in HRegion#replayRecoveredEdits and includes region-level tests. Credit for the baseline of this work all goes to our [~saitejar]. was: This task covers updating the clock on recovery in HRegion#replayRecoveredEdits and includes region-level tests. Credit for the baseline of this work all goes to our Sai Teja Ranuva. > Update clock on replaying recovered edits > - > > Key: HBASE-18510 > URL: https://issues.apache.org/jira/browse/HBASE-18510 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > This task covers updating the clock on recovery in > HRegion#replayRecoveredEdits and includes region-level tests. > Credit for the baseline of this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14756) Break out ClientBackoffPolicy factors into configurable and stackable components
[ https://issues.apache.org/jira/browse/HBASE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111997#comment-16111997 ] stack commented on HBASE-14756: --- Unscheduling good work that has not seen progress. Readd if think will make hbase2. > Break out ClientBackoffPolicy factors into configurable and stackable > components > > > Key: HBASE-14756 > URL: https://issues.apache.org/jira/browse/HBASE-14756 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Heng Chen > Attachments: HBASE-14756.patch > > > Currently ExponentialClientBackoffPolicy evaluates three load parameters sent > back in results from the server. The policy is fixed in implementation. > Instead it should be possible to define the collection of considered load > factors via configuration, and for each selected term parameterize how the > load factor should contribute to the backoff calculation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12217) System load average based client pushback
[ https://issues.apache.org/jira/browse/HBASE-12217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111993#comment-16111993 ] stack commented on HBASE-12217: --- Unscheduling good idea that has not seen progress in a while. > System load average based client pushback > - > > Key: HBASE-12217 > URL: https://issues.apache.org/jira/browse/HBASE-12217 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Andrew Purtell > > If a RegionServer host is already heavily loaded* then it might not be best > to accept more work in the form of coprocessor invocations. This could > generalize to all RPC work, perhaps as part of a broader admission control > initiative, but I think it makes sense to start small in an obvious place. > *: We could use % CPU utilization or the UNIX 1min or 5min load average to > determine this, and provide an option for choosing between those > alternatives. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14756) Break out ClientBackoffPolicy factors into configurable and stackable components
[ https://issues.apache.org/jira/browse/HBASE-14756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14756: -- Fix Version/s: (was: 1.4.0) (was: 2.0.0) > Break out ClientBackoffPolicy factors into configurable and stackable > components > > > Key: HBASE-14756 > URL: https://issues.apache.org/jira/browse/HBASE-14756 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Heng Chen > Attachments: HBASE-14756.patch > > > Currently ExponentialClientBackoffPolicy evaluates three load parameters sent > back in results from the server. The policy is fixed in implementation. > Instead it should be possible to define the collection of considered load > factors via configuration, and for each selected term parameterize how the > load factor should contribute to the backoff calculation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12217) System load average based client pushback
[ https://issues.apache.org/jira/browse/HBASE-12217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12217: -- Fix Version/s: (was: 1.5.0) (was: 2.0.0) > System load average based client pushback > - > > Key: HBASE-12217 > URL: https://issues.apache.org/jira/browse/HBASE-12217 > Project: HBase > Issue Type: New Feature >Reporter: Andrew Purtell >Assignee: Andrew Purtell > > If a RegionServer host is already heavily loaded* then it might not be best > to accept more work in the form of coprocessor invocations. This could > generalize to all RPC work, perhaps as part of a broader admission control > initiative, but I think it makes sense to start small in an obvious place. > *: We could use % CPU utilization or the UNIX 1min or 5min load average to > determine this, and provide an option for choosing between those > alternatives. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14272) Enforce major compaction on stores with TTL or time.to.purge.deletes enabled
[ https://issues.apache.org/jira/browse/HBASE-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111990#comment-16111990 ] stack commented on HBASE-14272: --- Unscheduling old non-critical that has open questions still. > Enforce major compaction on stores with TTL or time.to.purge.deletes enabled > > > Key: HBASE-14272 > URL: https://issues.apache.org/jira/browse/HBASE-14272 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Lars Hofhansl > Attachments: HBASE-14272.patch, HBASE-14272-v2.patch > > > Currently, if store has one (major compacted) file, the only case when major > compaction will be triggered for this file again - when locality is below > threshold, defined by *hbase.hstore.min.locality.to.skip.major.compact* or > TTL expired some cells. If file has locality greater than this threshold it > will never be major compacted until Store's TTL kicks in. For CF with > KEEP_DELETED_CELLS on, compaction must be enabled always (even for single > file), regardless of locality, when deleted cells are expired > (*hbase.hstore.time.to.purge.deletes*) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-14272) Enforce major compaction on stores with TTL or time.to.purge.deletes enabled
[ https://issues.apache.org/jira/browse/HBASE-14272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-14272: -- Fix Version/s: (was: 2.0.0) > Enforce major compaction on stores with TTL or time.to.purge.deletes enabled > > > Key: HBASE-14272 > URL: https://issues.apache.org/jira/browse/HBASE-14272 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Lars Hofhansl > Attachments: HBASE-14272.patch, HBASE-14272-v2.patch > > > Currently, if store has one (major compacted) file, the only case when major > compaction will be triggered for this file again - when locality is below > threshold, defined by *hbase.hstore.min.locality.to.skip.major.compact* or > TTL expired some cells. If file has locality greater than this threshold it > will never be major compacted until Store's TTL kicks in. For CF with > KEEP_DELETED_CELLS on, compaction must be enabled always (even for single > file), regardless of locality, when deleted cells are expired > (*hbase.hstore.time.to.purge.deletes*) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-13652) Case-insensitivity of file system affects table creation
[
https://issues.apache.org/jira/browse/HBASE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111988#comment-16111988
]
stack commented on HBASE-13652:
---
Unscheduling. Would be cool too if we just asked what system is and if
case-insensitive os, just do right thing rather than set flag.
> Case-insensitivity of file system affects table creation
>
>
> Key: HBASE-13652
> URL: https://issues.apache.org/jira/browse/HBASE-13652
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.0.0
> Environment: HBase standalone mode on Mac OS X.
>Reporter: Lars George
>Assignee: Xuesen Liang
> Labels: beginner
> Attachments: HBASE-13652.master.001.patch,
> HBASE-13652.master.002.patch, HBASE-13652.master.003.patch,
> HBASE-13652.master.004.patch, HBASE-13652.master.005.patch
>
>
> I noticed this on my Mac OS machine:
> {noformat}
> hbase(main):003:0> list
> TABLE
>
>
> 0 row(s) in 0.0260 seconds
> => []
> hbase(main):004:0> create 'TestTable', 'info'
> 0 row(s) in 0.2830 seconds
> => Hbase::Table - TestTable
> hbase(main):005:0> create 'testtable', 'colfam1'
> 0 row(s) in 0.1750 seconds
> => Hbase::Table - testtable
> hbase(main):006:0> list
> TABLE
>
>
> TestTable
>
>
> TestTable
>
>
> 2 row(s) in 0.0170 seconds
> => ["TestTable", "TestTable"]
> hbase(main):007:0> status 'detailed'
> version 1.0.0
> 0 regionsInTransition
> master coprocessors: []
> 1 live servers
> de1-app-mba-1.internal.larsgeorge.com:58824 1431124680152
> requestsPerSecond=0.0, numberOfOnlineRegions=4, usedHeapMB=47,
> maxHeapMB=4062, numberOfStores=4, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=16, writeRequestsCount=8,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> coprocessors=[]
> "TestTable,,1431124762491.cb30b003b192aa1d429e5a8e908a2f7d."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:meta,,1"
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=10, writeRequestsCount=6,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:namespace,,1431124686536.42728f3a3411b0d8ff21c7a2622d9378."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "testtable,,1431124773352.8d461d5069d1c88bc3b26562ab30e333."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> 0 dead servers
> {noformat}
> and on the file system there is
> {noformat}
> larsgeorge:~$ ls -l hbase/data/default/
> total 0
> drwxr-xr-x 7 larsgeorge staff 238 May 8 15:39 TestTable
> {noformat}
> This should not happen on a case sensitive file system (I presume), so is of
> marginal importance. But a simple extra check during directory creation could
> fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-13652) Case-insensitivity of file system affects table creation
[
https://issues.apache.org/jira/browse/HBASE-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13652:
--
Fix Version/s: (was: 2.0.0)
> Case-insensitivity of file system affects table creation
>
>
> Key: HBASE-13652
> URL: https://issues.apache.org/jira/browse/HBASE-13652
> Project: HBase
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.0.0
> Environment: HBase standalone mode on Mac OS X.
>Reporter: Lars George
>Assignee: Xuesen Liang
> Labels: beginner
> Attachments: HBASE-13652.master.001.patch,
> HBASE-13652.master.002.patch, HBASE-13652.master.003.patch,
> HBASE-13652.master.004.patch, HBASE-13652.master.005.patch
>
>
> I noticed this on my Mac OS machine:
> {noformat}
> hbase(main):003:0> list
> TABLE
>
>
> 0 row(s) in 0.0260 seconds
> => []
> hbase(main):004:0> create 'TestTable', 'info'
> 0 row(s) in 0.2830 seconds
> => Hbase::Table - TestTable
> hbase(main):005:0> create 'testtable', 'colfam1'
> 0 row(s) in 0.1750 seconds
> => Hbase::Table - testtable
> hbase(main):006:0> list
> TABLE
>
>
> TestTable
>
>
> TestTable
>
>
> 2 row(s) in 0.0170 seconds
> => ["TestTable", "TestTable"]
> hbase(main):007:0> status 'detailed'
> version 1.0.0
> 0 regionsInTransition
> master coprocessors: []
> 1 live servers
> de1-app-mba-1.internal.larsgeorge.com:58824 1431124680152
> requestsPerSecond=0.0, numberOfOnlineRegions=4, usedHeapMB=47,
> maxHeapMB=4062, numberOfStores=4, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=16, writeRequestsCount=8,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> coprocessors=[]
> "TestTable,,1431124762491.cb30b003b192aa1d429e5a8e908a2f7d."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:meta,,1"
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=10, writeRequestsCount=6,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "hbase:namespace,,1431124686536.42728f3a3411b0d8ff21c7a2622d9378."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=6, writeRequestsCount=2,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> "testtable,,1431124773352.8d461d5069d1c88bc3b26562ab30e333."
> numberOfStores=1, numberOfStorefiles=0,
> storefileUncompressedSizeMB=0, storefileSizeMB=0, memstoreSizeMB=0,
> storefileIndexSizeMB=0, readRequestsCount=0, writeRequestsCount=0,
> rootIndexSizeKB=0, totalStaticIndexSizeKB=0, totalStaticBloomSizeKB=0,
> totalCompactingKVs=0, currentCompactedKVs=0, compactionProgressPct=NaN,
> completeSequenceId=-1, dataLocality=0.0
> 0 dead servers
> {noformat}
> and on the file system there is
> {noformat}
> larsgeorge:~$ ls -l hbase/data/default/
> total 0
> drwxr-xr-x 7 larsgeorge staff 238 May 8 15:39 TestTable
> {noformat}
> This should not happen on a case sensitive file system (I presume), so is of
> marginal importance. But a simple extra check during directory creation could
> fix this.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12636) Avoid too many write operations on zookeeper in replication
[ https://issues.apache.org/jira/browse/HBASE-12636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111982#comment-16111982 ] stack commented on HBASE-12636: --- My guess is this is still a problem. Unscheduling though till someone takes it up in context of current hbase. > Avoid too many write operations on zookeeper in replication > --- > > Key: HBASE-12636 > URL: https://issues.apache.org/jira/browse/HBASE-12636 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.11 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Labels: replication > Attachments: HBASE-12635-v2.diff, HBASE-12636-v1.diff > > > In our production cluster, we found there are about over 1k write operations > per second on zookeeper from hbase replication. The reason is that the > replication source will write the log position to zookeeper for every edit > shipping. If the current replicating WAL is just the WAL that regionserver is > writing to, each skipping will be very small but the frequency is very high, > which causes many write operations on zookeeper. > A simple solution is that writing log position to zookeeper when position > diff or skipped edit number is larger than a threshold, not every edit > shipping. > Suggestions are welcomed, thx~ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12636) Avoid too many write operations on zookeeper in replication
[ https://issues.apache.org/jira/browse/HBASE-12636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12636: -- Fix Version/s: (was: 2.0.0) > Avoid too many write operations on zookeeper in replication > --- > > Key: HBASE-12636 > URL: https://issues.apache.org/jira/browse/HBASE-12636 > Project: HBase > Issue Type: Improvement >Affects Versions: 0.94.11 >Reporter: Liu Shaohui >Assignee: Liu Shaohui > Labels: replication > Attachments: HBASE-12635-v2.diff, HBASE-12636-v1.diff > > > In our production cluster, we found there are about over 1k write operations > per second on zookeeper from hbase replication. The reason is that the > replication source will write the log position to zookeeper for every edit > shipping. If the current replicating WAL is just the WAL that regionserver is > writing to, each skipping will be very small but the frequency is very high, > which causes many write operations on zookeeper. > A simple solution is that writing log position to zookeeper when position > diff or skipped edit number is larger than a threshold, not every edit > shipping. > Suggestions are welcomed, thx~ -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12349) Add Maven build support module for a custom version of error-prone
[ https://issues.apache.org/jira/browse/HBASE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111979#comment-16111979 ] stack commented on HBASE-12349: --- This looks interesting Mr Drob. What does a tarball have in it? The jars are hbase-*.jar or hbase-build-support-*.jar? > Add Maven build support module for a custom version of error-prone > -- > > Key: HBASE-12349 > URL: https://issues.apache.org/jira/browse/HBASE-12349 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Mike Drob > Fix For: 2.0.0 > > Attachments: HBASE-12349.patch, HBASE-12349.v2.patch, > HBASE-12349.v3.patch, HBASE-12349.v4.patch > > > Add a new Maven build support module that builds and publishes a custom > error-prone artifact for use by the rest of the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
