[jira] [Updated] (HBASE-20965) Separate region server report requests to new handlers
[ https://issues.apache.org/jira/browse/HBASE-20965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yi Mei updated HBASE-20965: --- Attachment: HBASE-20965.master.011.patch > Separate region server report requests to new handlers > -- > > Key: HBASE-20965 > URL: https://issues.apache.org/jira/browse/HBASE-20965 > Project: HBase > Issue Type: Improvement > Components: Performance >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-20965.master.001.patch, > HBASE-20965.master.002.patch, HBASE-20965.master.003.patch, > HBASE-20965.master.004.patch, HBASE-20965.master.005.patch, > HBASE-20965.master.006.patch, HBASE-20965.master.007.patch, > HBASE-20965.master.008.patch, HBASE-20965.master.009.patch, > HBASE-20965.master.010.patch, HBASE-20965.master.011.patch > > > In master rpc scheduler, all rpc requests are executed in a thread pool. This > task separates rs report requests to new handlers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572831#comment-16572831 ] Chia-Ping Tsai commented on HBASE-21012: bq. HFiles generated by 2.0.0+, 2.0.1+, and 2.1.0+ Please remove the "+" since the releases impacted by HBASE-18754 are 2.0.0, 2.0.1 and 2.1.0 rather than all unreleased versions. bq. Why HFile lose compatability is hbase in new versions (2.0.0+) ditto. change 2.0.0+ to 2.0.0, 2.0.1 and 2.1.0. Please help me to accurately document the release version affected by HBASE-18754. :) > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuan-Po Tseng updated HBASE-21012: -- Attachment: HBASE-21012.master.003.patch > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572872#comment-16572872 ] Kuan-Po Tseng commented on HBASE-21012: --- All done. > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20881) Introduce a region transition procedure to handle all the state transition for a region
[ https://issues.apache.org/jira/browse/HBASE-20881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-20881: -- Attachment: HBASE-20881-v6.patch > Introduce a region transition procedure to handle all the state transition > for a region > --- > > Key: HBASE-20881 > URL: https://issues.apache.org/jira/browse/HBASE-20881 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-20881-v1.patch, HBASE-20881-v2.patch, > HBASE-20881-v3.patch, HBASE-20881-v4.patch, HBASE-20881-v4.patch, > HBASE-20881-v5.patch, HBASE-20881-v6.patch, HBASE-20881.patch > > > Now have an AssignProcedure, an UnssignProcedure, and also a > MoveRegionProcedure which schedules an AssignProcedure and an > UnssignProcedure to move a region. This makes the logic a bit complicated, as > MRP is not a RIT, so when SCP can not interrupt it directly... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (HBASE-21025) Add cache for TableStateManager
Duo Zhang created HBASE-21025: - Summary: Add cache for TableStateManager Key: HBASE-21025 URL: https://issues.apache.org/jira/browse/HBASE-21025 Project: HBase Issue Type: Sub-task Reporter: Duo Zhang After HBASE-20881, we will check whether a table is disabled in SCP, so we need to add cache for it to improve MTTR, and also reduce the request to meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572945#comment-16572945
]
Toshihiro Suzuki commented on HBASE-21014:
--
Hi [~harisekhon],
I think we can't avoid to lose data localities for HBase when you run the HDFS
balancer. This is because HDFS doesn't know the region locations and it doesn't
take the locations into account for block balancing. This is the same even when
you use FavoredNodeLoadBalancer. If you need to run HDFS balancer, we can run
major compaction after that to recover the data localities.
Thanks.
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572945#comment-16572945
]
Toshihiro Suzuki edited comment on HBASE-21014 at 8/8/18 9:43 AM:
--
Hi [~harisekhon],
I think we can't avoid to lose data localities for HBase when you run the HDFS
balancer. This is because HDFS doesn't know the region locations and it doesn't
take the locations into account for block balancing. This is the same even when
you use FavoredNodeLoadBalancer. If you need to run HDFS balancer, you can run
major compaction after that to recover the data localities.
Thanks.
was (Author: brfrn169):
Hi [~harisekhon],
I think we can't avoid to lose data localities for HBase when you run the HDFS
balancer. This is because HDFS doesn't know the region locations and it doesn't
take the locations into account for block balancing. This is the same even when
you use FavoredNodeLoadBalancer. If you need to run HDFS balancer, we can run
major compaction after that to recover the data localities.
Thanks.
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuan-Po Tseng updated HBASE-21012: -- Attachment: HBASE-21012.master.003.patch Status: Patch Available (was: Open) resubmit patch. > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch, > HBASE-21012.master.003.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20972) Fix call queue buffer size leaking bug
[ https://issues.apache.org/jira/browse/HBASE-20972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572964#comment-16572964 ] Guanghao Zhang commented on HBASE-20972: Maybe name "resetCallSizeFromQueue"? > Fix call queue buffer size leaking bug > -- > > Key: HBASE-20972 > URL: https://issues.apache.org/jira/browse/HBASE-20972 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20972.branch-2.0.001.patch, > HBASE-20972.master.001.patch > > > Call queue size is the currently queued and running Calls bytes size. It gets > incremented after we parse a call and before we add it to the queue of calls > for the scheduler to use. It get decremented after we have 'run' the Call. > When setting up a call, total size of it is added. So when a new call can not > be dispatched by BlockingQueue full, the call queue size should be > decremented. We shouldn't add size of rejected calls to the call queue size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20965) Separate region server report requests to new handlers
[
https://issues.apache.org/jira/browse/HBASE-20965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16572967#comment-16572967
]
Hadoop QA commented on HBASE-20965:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} hbase-server: The patch generated 0 new + 76
unchanged - 1 fixed = 76 total (was 77) {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} shadedjars {color} | {color:green} 4m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 58s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}116m
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}156m 43s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-20965 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934766/HBASE-20965.master.011.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c79dcc3ef502 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 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 / d921262d38 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/13976/testReport/ |
| Max. process+thread count | 4904 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13976/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache
[jira] [Commented] (HBASE-20894) Move BucketCache from java serialization to protobuf
[ https://issues.apache.org/jira/browse/HBASE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573011#comment-16573011 ] Anoop Sam John commented on HBASE-20894: RL looks good. > Move BucketCache from java serialization to protobuf > > > Key: HBASE-20894 > URL: https://issues.apache.org/jira/browse/HBASE-20894 > Project: HBase > Issue Type: Task > Components: BucketCache >Affects Versions: 2.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-Write-the-CacheableDeserializerIdManager-index-into-.patch, > HBASE-20894.WIP-2.patch, HBASE-20894.WIP.patch, HBASE-20894.master.001.patch, > HBASE-20894.master.002.patch, HBASE-20894.master.003.patch, > HBASE-20894.master.004.patch, HBASE-20894.master.005.patch, > HBASE-20894.master.006.patch > > > We should use a better serialization format instead of Java Serialization for > the BucketCache entry persistence. > Suggested by Chris McCown, who does not appear to have a JIRA account. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21007) Memory leak in HBase rest server
[
https://issues.apache.org/jira/browse/HBASE-21007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573012#comment-16573012
]
Hudson commented on HBASE-21007:
Results for branch branch-1
[build #406 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Memory leak in HBase rest server
>
>
> Key: HBASE-21007
> URL: https://issues.apache.org/jira/browse/HBASE-21007
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 1.4.0, 1.4.6
>Reporter: Bosko Devetak
>Assignee: Bosko Devetak
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21007.001.patch, HBASE-21007.002.patch
>
>
> When using the URIs like this:
>
> /sometable/*?limit=$limit&startrow=$startrow&endrow=$endrow
>
> where *$limit* is smaller than the range between *$startrow* and *$endrow*,
> the rest server will start leaking memory.
>
>
> The bug is in the *TableScanResource.java* class. Basically, the
> ResultScanner is not being closed in next() method when the limit has been
> reached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20845) Support set the consistency for Gets and Scans in thrift2
[
https://issues.apache.org/jira/browse/HBASE-20845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573013#comment-16573013
]
Hudson commented on HBASE-20845:
Results for branch branch-1
[build #406 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1/406//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Support set the consistency for Gets and Scans in thrift2
> -
>
> Key: HBASE-20845
> URL: https://issues.apache.org/jira/browse/HBASE-20845
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0
>
> Attachments: HBASE-20845-branch-1.patch,
> HBASE-20845.master.001.patch, HBASE-20845.master.002.patch
>
>
> Support set the consistency for Gets and Scans in thrift2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20985) add two attributes when we do normalization
[ https://issues.apache.org/jira/browse/HBASE-20985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573014#comment-16573014 ] Jingyun Tian commented on HBASE-20985: -- [~zghaobac] yeah... My bad. > add two attributes when we do normalization > --- > > Key: HBASE-20985 > URL: https://issues.apache.org/jira/browse/HBASE-20985 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 2.1.0 > > Attachments: HBASE-20985.master.001.patch, > HBASE-20985.master.002.patch, HBASE-20985.master.003.patch, > HBASE-20985.master.004.patch > > > Currently when we turn on normalization switch, it will help balance the > whole table based on total region size / total region count. I add two > attributes so that we can set total region count or average region size we > want to achieve when normalization done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20985) add two attributes when we do normalization
[ https://issues.apache.org/jira/browse/HBASE-20985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-20985: - Attachment: HBASE-20985.master.005.patch > add two attributes when we do normalization > --- > > Key: HBASE-20985 > URL: https://issues.apache.org/jira/browse/HBASE-20985 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 2.1.0 > > Attachments: HBASE-20985.master.001.patch, > HBASE-20985.master.002.patch, HBASE-20985.master.003.patch, > HBASE-20985.master.004.patch, HBASE-20985.master.005.patch > > > Currently when we turn on normalization switch, it will help balance the > whole table based on total region size / total region count. I add two > attributes so that we can set total region count or average region size we > want to achieve when normalization done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20881) Introduce a region transition procedure to handle all the state transition for a region
[
https://issues.apache.org/jira/browse/HBASE-20881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573110#comment-16573110
]
Hadoop QA commented on HBASE-20881:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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
1s{color} | {color:green} The patch appears to include 22 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
34s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} The patch hbase-protocol-shaded passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
31s{color} | {color:green} hbase-client: The patch generated 0 new + 2
unchanged - 84 fixed = 2 total (was 86) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
14s{color} | {color:green} hbase-procedure: The patch generated 0 new + 20
unchanged - 1 fixed = 20 total (was 21) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
15s{color} | {color:green} hbase-server: The patch generated 0 new + 249
unchanged - 68 fixed = 249 total (was 317) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
12s{color} | {color:green} The patch hbase-rsgroup passed checkstyle {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} shadedjars {color} | {color:green} 4m
31s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 56s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green}
1m 56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
2s{color} | {color:green} hbase-client in the patch passed. {colo
[jira] [Commented] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon commented on HBASE-21014:
-
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer does not move them and lose data
locality?
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon edited comment on HBASE-21014 at 8/8/18 12:37 PM:
--
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
was (Author: harisekhon):
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer does not move them and lose data
locality?
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon edited comment on HBASE-21014 at 8/8/18 12:44 PM:
--
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage (this very
nearly happened the first time I ran major compaction on this cluster but I
realised what was going on and took quick action to avoid an outage -
annoyingly there is not yet a major compaction cancel command in this version
of HBase)
was (Author: harisekhon):
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon edited comment on HBASE-21014 at 8/8/18 12:45 PM:
--
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage (this very
nearly happened the first time I ran major compaction on this cluster but I
realised what was going on and took quick action to avoid an outage -
annoyingly there is not yet a major compaction cancel command in this version
of HBase so it couldn't just be stopped once started and ran for several hours)
was (Author: harisekhon):
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage (this very
nearly happened the first time I ran major compaction on this cluster but I
realised what was going on and took quick action to avoid an outage -
annoyingly there is not yet a major compaction cancel command in this version
of HBase)
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon edited comment on HBASE-21014 at 8/8/18 12:46 PM:
--
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage as the prior
blocks are not removed (this very nearly happened the first time I ran major
compaction on this cluster but I realised what was going on and took quick
action to avoid an outage - annoyingly there is not yet a major compaction
cancel command in this version of HBase so it couldn't just be stopped once
started and ran for several hours)
was (Author: harisekhon):
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage (this very
nearly happened the first time I ran major compaction on this cluster but I
realised what was going on and took quick action to avoid an outage -
annoyingly there is not yet a major compaction cancel command in this version
of HBase so it couldn't just be stopped once started and ran for several hours)
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573153#comment-16573153
]
Hari Sekhon edited comment on HBASE-21014 at 8/8/18 1:01 PM:
-
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would cause space exhaustion resulting in an outage as the
prior blocks are not removed (this very nearly happened the first time I ran
major compaction on this cluster but I realised what was going on and took
quick action to avoid an outage - annoyingly there is not yet a major
compaction cancel command in this version of HBase so it couldn't just be
stopped once started and ran for several hours)
was (Author: harisekhon):
I thought that was the whole point of the FavoredNodeLoadBalancer - so that
HBase Balancer can write those HDFS hints based on the knowledge it has of
region locations so that HDFS Balancer can read the preferred location hints
and not move those blocks, therefore not losing data locality?
Normally I would just balance and then major compact but there are 2 issues
with running major compaction:
# performance impact - this cluster is production and heavily loaded
# this cluster is already running around 70-80% full which combined with HBase
rolling snapshots covering 4 days means that more than the one scheduled major
compaction a week would space exhaustion resulting in an outage as the prior
blocks are not removed (this very nearly happened the first time I ran major
compaction on this cluster but I realised what was going on and took quick
action to avoid an outage - annoyingly there is not yet a major compaction
cancel command in this version of HBase so it couldn't just be stopped once
started and ran for several hours)
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20845) Support set the consistency for Gets and Scans in thrift2
[
https://issues.apache.org/jira/browse/HBASE-20845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573213#comment-16573213
]
Hudson commented on HBASE-20845:
Results for branch master
[build #422 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/422/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Support set the consistency for Gets and Scans in thrift2
> -
>
> Key: HBASE-20845
> URL: https://issues.apache.org/jira/browse/HBASE-20845
> Project: HBase
> Issue Type: Improvement
> Components: Thrift
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0
>
> Attachments: HBASE-20845-branch-1.patch,
> HBASE-20845.master.001.patch, HBASE-20845.master.002.patch
>
>
> Support set the consistency for Gets and Scans in thrift2
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573211#comment-16573211
]
Hudson commented on HBASE-20813:
Results for branch master
[build #422 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/422/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21007) Memory leak in HBase rest server
[
https://issues.apache.org/jira/browse/HBASE-21007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573212#comment-16573212
]
Hudson commented on HBASE-21007:
Results for branch master
[build #422 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/422/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Memory leak in HBase rest server
>
>
> Key: HBASE-21007
> URL: https://issues.apache.org/jira/browse/HBASE-21007
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 1.4.0, 1.4.6
>Reporter: Bosko Devetak
>Assignee: Bosko Devetak
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21007.001.patch, HBASE-21007.002.patch
>
>
> When using the URIs like this:
>
> /sometable/*?limit=$limit&startrow=$startrow&endrow=$endrow
>
> where *$limit* is smaller than the range between *$startrow* and *$endrow*,
> the rest server will start leaking memory.
>
>
> The bug is in the *TableScanResource.java* class. Basically, the
> ResultScanner is not being closed in next() method when the limit has been
> reached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20965) Separate region server report requests to new handlers
[
https://issues.apache.org/jira/browse/HBASE-20965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573214#comment-16573214
]
Hudson commented on HBASE-20965:
Results for branch master
[build #422 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/422/]: (x)
*{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/master/422//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Separate region server report requests to new handlers
> --
>
> Key: HBASE-20965
> URL: https://issues.apache.org/jira/browse/HBASE-20965
> Project: HBase
> Issue Type: Improvement
> Components: Performance
>Reporter: Yi Mei
>Assignee: Yi Mei
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-20965.master.001.patch,
> HBASE-20965.master.002.patch, HBASE-20965.master.003.patch,
> HBASE-20965.master.004.patch, HBASE-20965.master.005.patch,
> HBASE-20965.master.006.patch, HBASE-20965.master.007.patch,
> HBASE-20965.master.008.patch, HBASE-20965.master.009.patch,
> HBASE-20965.master.010.patch, HBASE-20965.master.011.patch
>
>
> In master rpc scheduler, all rpc requests are executed in a thread pool. This
> task separates rs report requests to new handlers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20881) Introduce a region transition procedure to handle all the state transition for a region
[ https://issues.apache.org/jira/browse/HBASE-20881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573228#comment-16573228 ] Duo Zhang commented on HBASE-20881: --- Great, all green! > Introduce a region transition procedure to handle all the state transition > for a region > --- > > Key: HBASE-20881 > URL: https://issues.apache.org/jira/browse/HBASE-20881 > Project: HBase > Issue Type: Sub-task > Components: amv2, proc-v2 >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-20881-v1.patch, HBASE-20881-v2.patch, > HBASE-20881-v3.patch, HBASE-20881-v4.patch, HBASE-20881-v4.patch, > HBASE-20881-v5.patch, HBASE-20881-v6.patch, HBASE-20881.patch > > > Now have an AssignProcedure, an UnssignProcedure, and also a > MoveRegionProcedure which schedules an AssignProcedure and an > UnssignProcedure to move a region. This makes the logic a bit complicated, as > MRP is not a RIT, so when SCP can not interrupt it directly... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[
https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573279#comment-16573279
]
Hadoop QA commented on HBASE-21012:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
27s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
14s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
31s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
39s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
35s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
25s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m
32s{color} | {color:red} root: The patch generated 2 new + 3 unchanged - 0
fixed = 5 total (was 3) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 6m
7s{color} | {color:blue} patch has no errors when building the reference guide.
See footer for rendered docs, which you should manually inspect. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
9s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 34s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
50s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}188m
50s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
51s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}267m 36s{color} |
{color:black
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573288#comment-16573288 ] Chia-Ping Tsai commented on HBASE-21012: [~brandboat] any idea about the tests? I will test the patch locally in the meantime. [~jinghe] Would you please take a look? > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch, > HBASE-21012.master.003.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20985) add two attributes when we do normalization
[
https://issues.apache.org/jira/browse/HBASE-20985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573291#comment-16573291
]
Hadoop QA commented on HBASE-20985:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 2 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
54s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
14s{color} | {color:red} The patch generated 7 new + 686 unchanged - 4 fixed =
693 total (was 690) {color} |
| {color:orange}-0{color} | {color:orange} ruby-lint {color} | {color:orange}
0m 20s{color} | {color:orange} The patch generated 29 new + 1324 unchanged - 0
fixed = 1353 total (was 1324) {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} shadedjars {color} | {color:green} 4m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
9m 59s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
9s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
5s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m
30s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
23s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
30s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}171m 58s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-20985 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934797/HBASE-20985.master.005.patch
|
| Optional Tests | asflicens
[jira] [Assigned] (HBASE-21018) RS crashed because AsyncFS was unable to update HDFS data encryption key
[
https://issues.apache.org/jira/browse/HBASE-21018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu reassigned HBASE-21018:
--
Assignee: Wei-Chiu Chuang
> RS crashed because AsyncFS was unable to update HDFS data encryption key
>
>
> Key: HBASE-21018
> URL: https://issues.apache.org/jira/browse/HBASE-21018
> Project: HBase
> Issue Type: Bug
> Components: wal
>Affects Versions: 2.0.0
> Environment: Hadoop 3.0.0, HBase 2.0.0,
> HDFS configuration dfs.encrypt.data.transfer = true
>Reporter: Wei-Chiu Chuang
>Assignee: Wei-Chiu Chuang
>Priority: Critical
> Attachments: HBASE-21018.master.001.patch
>
>
> We (+[~uagashe]) found HBase RegionServer doesn't update HDFS data encryption
> key correctly, and in some cases after retry 10 times, it aborts.
> {noformat}
> 2018-08-03 17:37:03,233 WARN
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputHelper: create
> fan-out dfs output
> /hbase/WALs/rs1.example.com,22101,1533318719239/rs1.example.com%2C22101%2C1533318719239.rs1.example.com%2C22101%2C1533318719239.regiongroup-0.1533343022981
> failed, retry = 1
> org.apache.hadoop.hdfs.protocol.datatransfer.InvalidEncryptionKeyException:
> Can't re-compute encryption key for nonce, since the required block key
> (keyID=1685436998) doesn't exist. Current key: 1085959374
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputSaslHelper$SaslNegotiateHandler.check(FanOutOneBlockAsyncDFSOutputSaslHelper.java:399)
> at
> org.apache.hadoop.hbase.io.asyncfs.FanOutOneBlockAsyncDFSOutputSaslHelper$SaslNegotiateHandler.channelRead(FanOutOneBlockAsyncDFSOutputSaslHelper.java:470)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at
> org.apache.hbase.thirdparty.io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:102)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at
> org.apache.hbase.thirdparty.io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
> at
> org.apache.hbase.thirdparty.io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at
> org.apache.hbase.thirdparty.io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:286)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
> at
> org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1359)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
> at
> org.apache.hbase.thirdparty.io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
> at
> org.apache.hbase.thirdparty.io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:935)
> at
> org.apache.hbase.thirdparty.io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:801)
> at
> org.apache.hbase.thirdparty.io.netty.channel.
[jira] [Assigned] (HBASE-21025) Add cache for TableStateManager
[ https://issues.apache.org/jira/browse/HBASE-21025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reassigned HBASE-21025: - Assignee: Duo Zhang > Add cache for TableStateManager > --- > > Key: HBASE-21025 > URL: https://issues.apache.org/jira/browse/HBASE-21025 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > > After HBASE-20881, we will check whether a table is disabled in SCP, so we > need to add cache for it to improve MTTR, and also reduce the request to meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21025) Add cache for TableStateManager
[ https://issues.apache.org/jira/browse/HBASE-21025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21025: -- Attachment: HBASE-21025.patch > Add cache for TableStateManager > --- > > Key: HBASE-21025 > URL: https://issues.apache.org/jira/browse/HBASE-21025 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Attachments: HBASE-21025.patch > > > After HBASE-20881, we will check whether a table is disabled in SCP, so we > need to add cache for it to improve MTTR, and also reduce the request to meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21025) Add cache for TableStateManager
[ https://issues.apache.org/jira/browse/HBASE-21025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21025: -- Fix Version/s: 2.1.1 2.2.0 3.0.0 Status: Patch Available (was: Open) > Add cache for TableStateManager > --- > > Key: HBASE-21025 > URL: https://issues.apache.org/jira/browse/HBASE-21025 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21025.patch > > > After HBASE-20881, we will check whether a table is disabled in SCP, so we > need to add cache for it to improve MTTR, and also reduce the request to meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573391#comment-16573391 ] Kuan-Po Tseng commented on HBASE-21012: --- [~chia7712] I have already test the patch locally, but I have no idea about how to write the test since it cross two different hbase branches... > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch, > HBASE-21012.master.003.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20988) TestShell shouldn't be skipped for hbase-shell module test
[
https://issues.apache.org/jira/browse/HBASE-20988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573396#comment-16573396
]
Sean Busbey commented on HBASE-20988:
-
Is this specific to TestShell? Do you want the bot to say something different
if any given module has any tests in the exclusion list?
What's the pro/con for QABot saying "+0 hbase-shell passed, but it had excluded
tests" vs updating the QABot to ensure any tests changed by the submitted patch
are run?
> TestShell shouldn't be skipped for hbase-shell module test
> --
>
> Key: HBASE-20988
> URL: https://issues.apache.org/jira/browse/HBASE-20988
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Priority: Major
>
> Here is snippet for QA run 13862 for HBASE-20985 :
> {code}
> 13:42:50 cd /testptch/hbase/hbase-shell
> 13:42:50 /usr/share/maven/bin/mvn
> -Dmaven.repo.local=/home/jenkins/yetus-m2/hbase-master-patch-1
> -DHBasePatchProcess -PrunAllTests
> -Dtest.exclude.pattern=**/master.normalizer.
> TestSimpleRegionNormalizerOnCluster.java,**/replication.regionserver.TestSerialReplicationEndpoint.java,**/master.procedure.TestServerCrashProcedure.java,**/master.procedure.TestCreateTableProcedure.
>
> java,**/TestClientOperationTimeout.java,**/client.TestSnapshotFromClientWithRegionReplicas.java,**/master.TestAssignmentManagerMetrics.java,**/client.TestShell.java,**/client.
>
> TestCloneSnapshotFromClientWithRegionReplicas.java,**/master.TestDLSFSHLog.java,**/replication.TestReplicationSmallTestsSync.java,**/master.procedure.TestModifyTableProcedure.java,**/regionserver.
>
> TestCompactionInDeadRegionServer.java,**/client.TestFromClientSide3.java,**/master.procedure.TestRestoreSnapshotProcedure.java,**/client.TestRestoreSnapshotFromClient.java,**/security.access.
>
> TestCoprocessorWhitelistMasterObserver.java,**/replication.regionserver.TestDrainReplicationQueuesForStandBy.java,**/master.procedure.TestProcedurePriority.java,**/master.locking.TestLockProcedure.
>
> java,**/master.cleaner.TestSnapshotFromMaster.java,**/master.assignment.TestSplitTableRegionProcedure.java,**/client.TestMobRestoreSnapshotFromClient.java,**/replication.TestReplicationKillSlaveRS.
>
> java,**/regionserver.TestHRegion.java,**/security.access.TestAccessController.java,**/master.procedure.TestTruncateTableProcedure.java,**/client.TestAsyncReplicationAdminApiWithClusters.java,**/
>
> coprocessor.TestMetaTableMetrics.java,**/client.TestMobSnapshotCloneIndependence.java,**/namespace.TestNamespaceAuditor.java,**/master.TestMasterAbortAndRSGotKilled.java,**/client.TestAsyncTable.java,**/master.TestMasterOperationsForRegionReplicas.java,**/util.TestFromClientSide3WoUnsafe.java,**/client.TestSnapshotCloneIndependence.java,**/client.TestAsyncDecommissionAdminApi.java,**/client.
>
> TestRestoreSnapshotFromClientWithRegionReplicas.java,**/master.assignment.TestMasterAbortWhileMergingTable.java,**/client.TestFromClientSide.java,**/client.TestAdmin1.java,**/client.
>
> TestFromClientSideWithCoprocessor.java,**/replication.TestReplicationKillSlaveRSWithSeparateOldWALs.java,**/master.procedure.TestMasterFailoverWithProcedures.java,**/regionserver.
> TestSplitTransactionOnCluster.java clean test -fae >
> /testptch/patchprocess/patch-unit-hbase-shell.txt 2>&1
> {code}
> In this case, there was modification to shell script, leading to running
> shell tests.
> However, TestShell was excluded in the QA run, defeating the purpose.
> Meanwhile QA posted the following onto HBASE-20985 :
> bq. +1unit7m 4s hbase-shell in the patch passed.
> That is misleading - no related test was actually run.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jinghan xu updated HBASE-20943: --- Attachment: (was: HBASE-20943.patch) > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.0.0, 1.2.6.1 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943.patch, Screen Shot 2018-07-25 at 2.51.19 > PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jinghan xu updated HBASE-20943: --- Attachment: HBASE-20943.patch > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.0.0, 1.2.6.1 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943.patch, Screen Shot 2018-07-25 at 2.51.19 > PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573401#comment-16573401 ] jinghan xu commented on HBASE-20943: updated the number to count. > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.0.0, 1.2.6.1 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943.patch, Screen Shot 2018-07-25 at 2.51.19 > PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[ https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kuan-Po Tseng updated HBASE-21012: -- Attachment: HBASE-21012.master.004.patch > Revert the change of serializing TimeRangeTracker > - > > Key: HBASE-21012 > URL: https://issues.apache.org/jira/browse/HBASE-21012 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Kuan-Po Tseng >Priority: Critical > Fix For: 3.0.0, 2.0.2, 2.1.1 > > Attachments: HBASE-21012.master.001.patch, > HBASE-21012.master.002.patch, HBASE-21012.master.003.patch, > HBASE-21012.master.003.patch, HBASE-21012.master.004.patch > > > HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to > protobuf. However, the change breaks the backward compatibility of hfile. We > should revert the change ASAP. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21014) Improve Stochastic Balancer to write HDFS favoured node hints for region primary blocks to avoid destroying data locality if needing to use HDFS Balancer
[
https://issues.apache.org/jira/browse/HBASE-21014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573414#comment-16573414
]
Toshihiro Suzuki commented on HBASE-21014:
--
[~harisekhon]
{quote}
This is the same even when you use FavoredNodeLoadBalancer.
{quote}
Sorry, I was wrong. If you use FavoredNodeLoadBalancer, you need to set the
"dfs.datanode.block-pinning.enabled" property to true in the HDFS service
configuration. In this case, HDFS balancer won't move the hdfs blocks of the
hbase data, so you can run HDFS balancer without losing data locality.
Please see:
https://issues.apache.org/jira/browse/HBASE-7932
https://issues.apache.org/jira/browse/HDFS-6133
https://hbase.apache.org/book.html#_hbase_and_hdfs
> Improve Stochastic Balancer to write HDFS favoured node hints for region
> primary blocks to avoid destroying data locality if needing to use HDFS
> Balancer
> -
>
> Key: HBASE-21014
> URL: https://issues.apache.org/jira/browse/HBASE-21014
> Project: HBase
> Issue Type: Improvement
> Components: Balancer
>Affects Versions: 1.1.2
>Reporter: Hari Sekhon
>Priority: Major
>
> Improve Stochastic Balancer to include the HDFS region location hints to
> avoid HDFS Balancer destroying data locality.
> Right now according to a mix of docs, jiras and mailing list info it appears
> that one must change
> {code:java}
> hbase.master.loadbalancer.class{code}
> to the org.apache.hadoop.hbase.favored.FavoredNodeLoadBalancer as it looks
> like this functionality is only within FavoredNodeBalancer and not the
> standard Stochastic Balancer.
> [http://hbase.apache.org/book.html#_hbase_and_hdfs]
> This is not ideal because we'd still like to use all the heuristics and work
> that has gone in the Stochastic Balancer which I believe right now is the
> best and most mature HBase balancer.
> See also the linked Jiras and this discussion:
> [http://apache-hbase.679495.n3.nabble.com/HDFS-Balancer-td4086607.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-20943: - Attachment: HBASE-20943-master-v1.patch > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.0.0, 1.2.6.1 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943-master-v1.patch, HBASE-20943.patch, Screen > Shot 2018-07-25 at 2.51.19 PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] huaxiang sun updated HBASE-20943: - Status: Patch Available (was: Open) Hi jinghan, I rebased your patch with master branch, and submit it for a QA run. > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 1.2.6.1, 2.0.0 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943-master-v1.patch, HBASE-20943.patch, Screen > Shot 2018-07-25 at 2.51.19 PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20943) Add offline/online region count into metrics
[ https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573575#comment-16573575 ] huaxiang sun commented on HBASE-20943: -- I tested locally, the unittest passed and the metrics shows online/offline region counts correctly. > Add offline/online region count into metrics > > > Key: HBASE-20943 > URL: https://issues.apache.org/jira/browse/HBASE-20943 > Project: HBase > Issue Type: Improvement > Components: metrics >Affects Versions: 2.0.0, 1.2.6.1 >Reporter: Tianying Chang >Assignee: jinghan xu >Priority: Minor > Attachments: HBASE-20943-master-v1.patch, HBASE-20943.patch, Screen > Shot 2018-07-25 at 2.51.19 PM.png > > > We intensively use metrics to monitor the health of our HBase production > cluster. We have seen some regions of a table stuck and cannot be brought > online due to AWS issue which cause some log file corrupted. It will be good > if we can catch this early. Although WebUI has this information, it is not > useful for automated monitoring. By adding this metric, we can easily monitor > them with our monitoring system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573578#comment-16573578
]
Josh Elser commented on HBASE-20813:
Thanks, Duo and Stack. Pushing to 2.1 now and then will resolve.
Thanks, Sakthi, for this nice usability improvement.
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-20813:
---
Hadoop Flags: Reviewed
Release Note: In previous releases, when a Space Quota was configured on a
table or namespace and that table or namespace was deleted, the Space Quota was
also deleted. This change improves the implementation so that the same is also
done for RPC Quotas.
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21025) Add cache for TableStateManager
[
https://issues.apache.org/jira/browse/HBASE-21025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573582#comment-16573582
]
Hadoop QA commented on HBASE-21025:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
31s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
31s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
4s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
15s{color} | {color:red} hbase-server: The patch generated 4 new + 44 unchanged
- 10 fixed = 48 total (was 54) {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} shadedjars {color} | {color:green} 4m
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 1s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}120m 41s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
22s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}167m 16s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.master.procedure.TestMasterFailoverWithProcedures |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21025 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934826/HBASE-21025.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 7b7032c6bb0d 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 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 / d921262d38 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| checkstyle |
https://builds.apache.org/job/PreCommit-HBASE-Build/13980/artifact/patchprocess/diff-checkstyle-hbase-server.txt
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/13980/artifact/patchprocess/patch-unit-hbase-server.txt
[jira] [Created] (HBASE-21026) Fix Backup/Restore command usage bug in book
Mingliang Liu created HBASE-21026: - Summary: Fix Backup/Restore command usage bug in book Key: HBASE-21026 URL: https://issues.apache.org/jira/browse/HBASE-21026 Project: HBase Issue Type: Bug Components: backup&restore Reporter: Mingliang Liu Assignee: Mingliang Liu -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu updated HBASE-21026: -- Attachment: HBASE-21026.001.patch > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Major > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573593#comment-16573593 ] Mingliang Liu commented on HBASE-21026: --- [~yuzhih...@gmail.com] and [~elserj] mind taking a look? Thanks! > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Major > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu updated HBASE-21026: -- Priority: Minor (was: Major) > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu updated HBASE-21026: -- Affects Version/s: 2.0.0 Status: Patch Available (was: Open) > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Major > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu updated HBASE-21026: -- Component/s: documentation > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[
https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573620#comment-16573620
]
Josh Elser commented on HBASE-21012:
{quote}I have no idea about how to write the test since it cross two different
hbase branches...
{quote}
I'd suggest just including an HFile with the old serialization and including it
in {{src/test/resources}}. Then, you just write a test to make sure it can read
that old HFile version. You might want to look at test cases around HFile v3.
There may already be some backwards compat test cases you can mimic.
> Revert the change of serializing TimeRangeTracker
> -
>
> Key: HBASE-21012
> URL: https://issues.apache.org/jira/browse/HBASE-21012
> Project: HBase
> Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Kuan-Po Tseng
>Priority: Critical
> Fix For: 3.0.0, 2.0.2, 2.1.1
>
> Attachments: HBASE-21012.master.001.patch,
> HBASE-21012.master.002.patch, HBASE-21012.master.003.patch,
> HBASE-21012.master.003.patch, HBASE-21012.master.004.patch
>
>
> HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to
> protobuf. However, the change breaks the backward compatibility of hfile. We
> should revert the change ASAP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573622#comment-16573622 ] Josh Elser commented on HBASE-21026: LGTM, let's push on QA. > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-21022) Review kafka-connection repo's POMs
[ https://issues.apache.org/jira/browse/HBASE-21022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser resolved HBASE-21022. Resolution: Fixed > Review kafka-connection repo's POMs > --- > > Key: HBASE-21022 > URL: https://issues.apache.org/jira/browse/HBASE-21022 > Project: HBase > Issue Type: Task > Components: kafka >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Major > > Review the POMs introduced as a part of HBASE-20934 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mingliang Liu updated HBASE-21026: -- Attachment: HBASE-21026.002.patch > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573653#comment-16573653
]
Sakthi commented on HBASE-20813:
Thanks Josh, Stack, Duo for your involvement in this.
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573656#comment-16573656 ] Mingliang Liu commented on HBASE-21026: --- Thanks [~elserj] for prompt review. v002 also fixes the stale "s3fs" statement. > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[
https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573657#comment-16573657
]
Hadoop QA commented on HBASE-21026:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
32s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
58s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
48s{color} | {color:blue} patch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 18m 0s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21026 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934853/HBASE-21026.001.patch
|
| Optional Tests | asflicense refguide |
| uname | Linux 6a103817fc76 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 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 / d921262d38 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/13982/artifact/patchprocess/branch-site/book.html
|
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/13982/artifact/patchprocess/patch-site/book.html
|
| Max. process+thread count | 83 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13982/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Fix Backup/Restore command usage bug in book
>
>
> Key: HBASE-21026
> URL: https://issues.apache.org/jira/browse/HBASE-21026
> Project: HBase
> Issue Type: Bug
> Components: backup&restore, documentation
>Affects Versions: 2.0.0
>Reporter: Mingliang Liu
>Assignee: Mingliang Liu
>Priority: Minor
> Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573662#comment-16573662 ] Ted Yu commented on HBASE-21026: +1 > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated HBASE-20813:
---
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573696#comment-16573696 ] Vladimir Rodionov commented on HBASE-21026: --- lgtm > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[
https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573706#comment-16573706
]
Hadoop QA commented on HBASE-21026:
---
| (/) *{color:green}+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:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
25s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
15s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
2s{color} | {color:blue} patch has no errors when building the reference guide.
See footer for rendered docs, which you should manually inspect. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 16m 34s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21026 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934859/HBASE-21026.002.patch
|
| Optional Tests | asflicense refguide |
| uname | Linux 657b8cc87327 4.4.0-130-generic #156-Ubuntu SMP Thu Jun 14
08:53:28 UTC 2018 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 / d921262d38 |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/13984/artifact/patchprocess/branch-site/book.html
|
| refguide |
https://builds.apache.org/job/PreCommit-HBASE-Build/13984/artifact/patchprocess/patch-site/book.html
|
| Max. process+thread count | 93 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13984/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Fix Backup/Restore command usage bug in book
>
>
> Key: HBASE-21026
> URL: https://issues.apache.org/jira/browse/HBASE-21026
> Project: HBase
> Issue Type: Bug
> Components: backup&restore, documentation
>Affects Versions: 2.0.0
>Reporter: Mingliang Liu
>Assignee: Mingliang Liu
>Priority: Minor
> Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-21026: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 3.0.0 Status: Resolved (was: Patch Available) Thanks for the patch, Mingliang Thanks for the reviews. > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573733#comment-16573733
]
Mike Drob commented on HBASE-21005:
---
A little confused still. Let me try to make some statements that I believe to
be true and then you can correct where I'm misguided.
* Released versions of HBase will create the project.basedir directory.
* With this patch, future versions will not.
* The same is true to projects that depend on or transitively depend on HBase
* We fix this by publishing the maven skin in a "real" repository instead of in
our directory tree
Can you add to the comment explaining why we are pulling from your personal
maven GAV space with a link to the github fork? Is it
https://github.com/joshelser/maven-fluido-skin/tree/1.4-HBase-patched ?
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
Mike Drob created HBASE-21027: - Summary: Inconsistent synchronization in CacheableDeserializerIdManager Key: HBASE-21027 URL: https://issues.apache.org/jira/browse/HBASE-21027 Project: HBase Issue Type: Task Affects Versions: 3.0.0 Reporter: Mike Drob Assignee: Mike Drob Fix For: 3.0.0 There is some inconsistent synchronization going on in CDIM, we should switch it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-21027: -- Status: Patch Available (was: Open) > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-21027: -- Attachment: HBASE-21027.master.001.patch > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573744#comment-16573744
]
Sean Busbey commented on HBASE-21005:
-
why aren't we just publishing this jar as a part of {{hbase-thirdparty}}?
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573751#comment-16573751
]
Sean Busbey commented on HBASE-21005:
-
also please link to https://github.com/apache/maven-fluido-skin/pull/1 and/or
MSKINS-137 so we have some hope of getting back to basic artifacts at some
point.
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573752#comment-16573752
]
Josh Elser commented on HBASE-21005:
{quote}Let me try to make some statements that I believe to be true and then
you can correct where I'm misguided
{quote}
All true.
{quote}Can you add to the comment explaining why we are pulling from your
personal maven GAV space with a link to the github fork
{quote}
{quote}why aren't we just publishing this jar as a part of {{hbase-thirdparty}}?
{quote}
Because I could turn this around in ~2-3 hours and it is ultimately still
"throwaway". I didn't have motivation to spend time putting it into
hbase-thirdparty.
{quote}also please link to [https://github.com/apache/maven-fluido-skin/pull/1]
and/or MSKINS-137 so we have some hope of getting back to basic artifacts at
some point.
{quote}
Where do you want links to these?
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[
https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573753#comment-16573753
]
Sean Busbey commented on HBASE-21027:
-
{code}
68 // No synchronization here because weakly consistent view should be
good enough
69 return registeredDeserializers.entrySet().stream()
70 .collect(Collectors.toMap(Map.Entry::getKey, v ->
v.getClass().getName()));
{code}
weakly consistent is good enough because we only iterate once and we don't make
any changes to what a given key points at after inserting it? is that right?
> Inconsistent synchronization in CacheableDeserializerIdManager
> ---
>
> Key: HBASE-21027
> URL: https://issues.apache.org/jira/browse/HBASE-21027
> Project: HBase
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21027.master.001.patch
>
>
> There is some inconsistent synchronization going on in CDIM, we should switch
> it to using ConcurrentHashMap and simplify our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573757#comment-16573757
]
Sean Busbey commented on HBASE-21005:
-
{quote}
bq. why aren't we just publishing this jar as a part of hbase-thirdparty?
Because I could turn this around in ~2-3 hours and it is ultimately still
"throwaway". I didn't have motivation to spend time putting it into
hbase-thirdparty.
{quote}
fair cop.
{quote}
bq. also please link to https://github.com/apache/maven-fluido-skin/pull/1
and/or MSKINS-137 so we have some hope of getting back to basic artifacts at
some point.
Where do you want links to these?
{quote}
I would have said {{src/site/site.xml}}, but maybe just having it as a comment
here is enough since we already reference this jira at the place where I'd call
out "remove this after MSKINS-137 is fixed"? I have talked myself down to "nit"
status. :)
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573762#comment-16573762
]
Sean Busbey commented on HBASE-21005:
-
[~mdrob] the pom for the artifact also points back to Josh's forked repo and
branch, not sure if that's direct enough for your concern.
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573768#comment-16573768 ] Sean Busbey commented on HBASE-21027: - presuming I have the reasoning correct, I'm +1 pending QABot. > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21005) Maven site configuration causes downstream projects to get a directory named ${project.basedir}
[
https://issues.apache.org/jira/browse/HBASE-21005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573766#comment-16573766
]
Josh Elser commented on HBASE-21005:
{quote}I have talked myself down to "nit" status.
{quote}
hah! Happy to amend the comment to be more explicit about this on commit if
you'd like.
{quote}fair cop.
{quote}
Also, we've had their one-off JAR just hanging around in our repo which no one
batted an eye at (except in passing at release time). I figured coming from a
committer, it wasn't the end of the world. Don't want to be dunking on you –
it's just the truth that a "more proper" fix seemed unnecessary and we could
turn something around for downstream folks faster.
> Maven site configuration causes downstream projects to get a directory named
> ${project.basedir}
> ---
>
> Key: HBASE-21005
> URL: https://issues.apache.org/jira/browse/HBASE-21005
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 2.0.0
>Reporter: Matt Burgess
>Assignee: Josh Elser
>Priority: Minor
> Attachments: HBASE-21005.001.patch
>
>
> Matt told me about this interesting issue they see down in Apache Nifi's build
> NiFi depends on HBase for some code that they provide to their users. As a
> part of the build process of NiFi, they are seeing a directory named
> {{$\{project.basedir}}} get created the first time they build with an empty
> Maven repo. Matt reports that after a javax.el artifact is cached, Maven will
> stop creating the directory; however, if you wipe that artifact from the
> Maven repo, the next build will end up re-creating it.
> I believe I've seen this with Phoenix, too, but never investigated why it was
> actually happening.
> My hunch is that it's related to the local maven repo that we create to
> "patch" in our custom maven-fluido-skin jar (HBASE-14785). I'm not sure if we
> can "work" around this by pushing the custom local repo into a profile and
> only activating that for the mvn-site. Another solution would be to publish
> the maven-fluido-jar to central with custom coordinates.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573778#comment-16573778 ] Mike Drob commented on HBASE-21027: --- Yea, the concurrency risk is that if a serializer is registered while we are streaming, we aren't guaranteed to see it. Which is the same behavior if the serializer is registered after we finish taking the snapshot, something that is equally likely to be done by the thread scheduler. There is a more subtle risk where if elements (p, q) are added by a single thread in that sequence, we might see q but not p. I don't think this usage pattern exists in our code base though, where a thread would be registering multiple classes. > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21026) Fix Backup/Restore command usage bug in book
[ https://issues.apache.org/jira/browse/HBASE-21026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573791#comment-16573791 ] Mingliang Liu commented on HBASE-21026: --- Thanks! > Fix Backup/Restore command usage bug in book > > > Key: HBASE-21026 > URL: https://issues.apache.org/jira/browse/HBASE-21026 > Project: HBase > Issue Type: Bug > Components: backup&restore, documentation >Affects Versions: 2.0.0 >Reporter: Mingliang Liu >Assignee: Mingliang Liu >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-21026.001.patch, HBASE-21026.002.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-18477) Umbrella JIRA for HBase Read Replica clusters
[
https://issues.apache.org/jira/browse/HBASE-18477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573794#comment-16573794
]
Hudson commented on HBASE-18477:
Results for branch HBASE-18477
[build #289 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/289/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/289//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/289//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/289//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(x) {color:red}-1 client integration test{color}
--Failed when running client tests on top of Hadoop 2. [see log for
details|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/289//artifact/output-integration/hadoop-2.log].
(note that this means we didn't run on Hadoop 3)
> Umbrella JIRA for HBase Read Replica clusters
> -
>
> Key: HBASE-18477
> URL: https://issues.apache.org/jira/browse/HBASE-18477
> Project: HBase
> Issue Type: New Feature
>Reporter: Zach York
>Assignee: Zach York
>Priority: Major
> Attachments: HBase Read-Replica Clusters Scope doc.docx, HBase
> Read-Replica Clusters Scope doc.pdf, HBase Read-Replica Clusters Scope
> doc_v2.docx, HBase Read-Replica Clusters Scope doc_v2.pdf
>
>
> Recently, changes (such as HBASE-17437) have unblocked HBase to run with a
> root directory external to the cluster (such as in Amazon S3). This means
> that the data is stored outside of the cluster and can be accessible after
> the cluster has been terminated. One use case that is often asked about is
> pointing multiple clusters to one root directory (sharing the data) to have
> read resiliency in the case of a cluster failure.
>
> This JIRA is an umbrella JIRA to contain all the tasks necessary to create a
> read-replica HBase cluster that is pointed at the same root directory.
>
> This requires making the Read-Replica cluster Read-Only (no metadata
> operation or data operations).
> Separating the hbase:meta table for each cluster (Otherwise HBase gets
> confused with multiple clusters trying to update the meta table with their ip
> addresses)
> Adding refresh functionality for the meta table to ensure new metadata is
> picked up on the read replica cluster.
> Adding refresh functionality for HFiles for a given table to ensure new data
> is picked up on the read replica cluster.
>
> This can be used with any existing cluster that is backed by an external
> filesystem.
>
> Please note that this feature is still quite manual (with the potential for
> automation later).
>
> More information on this particular feature can be found here:
> https://aws.amazon.com/blogs/big-data/setting-up-read-replica-clusters-with-hbase-on-amazon-s3/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21007) Memory leak in HBase rest server
[
https://issues.apache.org/jira/browse/HBASE-21007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573808#comment-16573808
]
Hudson commented on HBASE-21007:
Results for branch branch-1.4
[build #411 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/411/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/411//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/411//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/411//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Memory leak in HBase rest server
>
>
> Key: HBASE-21007
> URL: https://issues.apache.org/jira/browse/HBASE-21007
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 1.4.0, 1.4.6
>Reporter: Bosko Devetak
>Assignee: Bosko Devetak
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21007.001.patch, HBASE-21007.002.patch
>
>
> When using the URIs like this:
>
> /sometable/*?limit=$limit&startrow=$startrow&endrow=$endrow
>
> where *$limit* is smaller than the range between *$startrow* and *$endrow*,
> the rest server will start leaking memory.
>
>
> The bug is in the *TableScanResource.java* class. Basically, the
> ResultScanner is not being closed in next() method when the limit has been
> reached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20705) Having RPC Quota on a table prevents Space quota to be recreated/removed
[
https://issues.apache.org/jira/browse/HBASE-20705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573817#comment-16573817
]
Sakthi commented on HBASE-20705:
[~elserj], the test failure look unrelated to my changes. Could you please
confirm?
> Having RPC Quota on a table prevents Space quota to be recreated/removed
>
>
> Key: HBASE-20705
> URL: https://issues.apache.org/jira/browse/HBASE-20705
> Project: HBase
> Issue Type: Bug
>Reporter: Biju Nair
>Assignee: Sakthi
>Priority: Major
> Attachments: hbase-20705.master.001.patch
>
>
> * Property {{hbase.quota.remove.on.table.delete}} is set to {{true}} by
> default
> * Create a table and set RPC and Space quota
> {noformat}
> hbase(main):022:0> create 't2','cf1'
> Created table t2
> Took 0.7420 seconds
> => Hbase::Table - t2
> hbase(main):023:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0105 seconds
> hbase(main):024:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0186 seconds
> hbase(main):025:0> list_quotas
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, LIMIT => 1073741824, VIOLATION_POLICY
> => NO_WRITES{noformat}
> * Drop the table and the Space quota is set to {{REMOVE => true}}
> {noformat}
> hbase(main):026:0> disable 't2'
> Took 0.4363 seconds
> hbase(main):027:0> drop 't2'
> Took 0.2344 seconds
> hbase(main):028:0> list_quotas
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true
> USER => u1 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT => 10M/sec,
> SCOPE => MACHINE{noformat}
> * Recreate the table and set Space quota back. The Space quota on the table
> is still set to {{REMOVE => true}}
> {noformat}
> hbase(main):029:0> create 't2','cf1'
> Created table t2
> Took 0.7348 seconds
> => Hbase::Table - t2
> hbase(main):031:0> set_quota TYPE => SPACE, TABLE => 't2', LIMIT => '1G',
> POLICY => NO_WRITES
> Took 0.0088 seconds
> hbase(main):032:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE => true{noformat}
> * Remove RPC quota and drop the table, the Space Quota is not removed
> {noformat}
> hbase(main):033:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT => NONE
> Took 0.0193 seconds
> hbase(main):036:0> disable 't2'
> Took 0.4305 seconds
> hbase(main):037:0> drop 't2'
> Took 0.2353 seconds
> hbase(main):038:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => SPACE, TABLE => t2, REMOVE
> => true{noformat}
> * Deleting the quota entry from {{hbase:quota}} seems to be the option to
> reset it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[
https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573831#comment-16573831
]
Hadoop QA commented on HBASE-21012:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
29s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
17s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue} 5m
22s{color} | {color:blue} branch has no errors when building the reference
guide. See footer for rendered docs, which you should manually inspect. {color}
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
10s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
0s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
14s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
31s{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:blue}0{color} | {color:blue} refguide {color} | {color:blue} 6m
9s{color} | {color:blue} patch has no errors when building the reference guide.
See footer for rendered docs, which you should manually inspect. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
5s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 51s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
48s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}204m
38s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
53s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}284m 10s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes |
[jira] [Commented] (HBASE-20813) Remove RPC quotas when the associated table/Namespace is dropped off
[
https://issues.apache.org/jira/browse/HBASE-20813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573835#comment-16573835
]
Hudson commented on HBASE-20813:
Results for branch branch-2.1
[build #160 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/160/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(/) {color:green}+1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/160//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/160//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/160//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Remove RPC quotas when the associated table/Namespace is dropped off
>
>
> Key: HBASE-20813
> URL: https://issues.apache.org/jira/browse/HBASE-20813
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: hbase-20813.master.001.patch,
> hbase-20813.master.002.patch
>
>
> In short, the below scenario shouldn't be the case.
> {noformat}
> hbase(main):023:0> create 't2','cf1'
> Created table t2
> Took 0.7405 seconds
> => Hbase::Table - t2
> hbase(main):024:0>
> hbase(main):025:0*
> hbase(main):026:0* set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.0082 seconds
> hbase(main):027:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0291 seconds
> hbase(main):028:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0037 seconds
> hbase(main):029:0> disable 't2'
> Took 0.4328 seconds
> hbase(main):030:0> drop 't2'
> Took 0.2285 seconds
> hbase(main):031:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE => REQUEST_SIZE, LIMIT =>
> 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0230 seconds
> hbase(main):032:0> scan 'hbase:quota'
> ROW COLUMN+CELL
> t.t2 column=q:s, timestamp=1530165010888,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80\x05 \x02
> 1 row(s)
> Took 0.0038 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20943) Add offline/online region count into metrics
[
https://issues.apache.org/jira/browse/HBASE-20943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573853#comment-16573853
]
Hadoop QA commented on HBASE-20943:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
11s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
31s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
10s{color} | {color:red} hbase-hadoop-compat: The patch generated 1 new + 0
unchanged - 0 fixed = 1 total (was 0) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m
11s{color} | {color:red} hbase-server: The patch generated 3 new + 4 unchanged
- 0 fixed = 7 total (was 4) {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} shadedjars {color} | {color:green} 4m
28s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
10m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
1s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
28s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
34s{color} | {color:green} hbase-hadoop2-compat in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}118m 40s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
58s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}166m 14s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.TestSyncReplicationStandbyKillRS |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-20943 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934849/HBASE-20943-master-v1.patch
|
| Optional Tests | asflicense ja
[jira] [Commented] (HBASE-20995) Clean Up Manual Array Copies, trivial
[
https://issues.apache.org/jira/browse/HBASE-20995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573875#comment-16573875
]
Ted Yu commented on HBASE-20995:
For the change in HBaseAdmin:
{code}
835 if (startKeys.length - 1 >= 0) System.arraycopy(startKeys, 1,
splits, 0, startKeys.length - 1);
{code}
If startKeys.length == 1, the loop in original code wouldn't do anything.
> Clean Up Manual Array Copies, trivial
> -
>
> Key: HBASE-20995
> URL: https://issues.apache.org/jira/browse/HBASE-20995
> Project: HBase
> Issue Type: Improvement
>Reporter: John Leach
>Assignee: John Leach
>Priority: Trivial
> Attachments: HBASE-20995.patch
>
>
> Clean up manual array copies in code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21007) Memory leak in HBase rest server
[
https://issues.apache.org/jira/browse/HBASE-21007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573927#comment-16573927
]
Hudson commented on HBASE-21007:
Results for branch branch-1.2
[build #422 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/422/]:
(x) *{color:red}-1 overall{color}*
details (if available):
(x) {color:red}-1 general checks{color}
-- For more information [see general
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/422//General_Nightly_Build_Report/]
(x) {color:red}-1 jdk7 checks{color}
-- For more information [see jdk7
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/422//JDK7_Nightly_Build_Report/]
(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.2/422//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> Memory leak in HBase rest server
>
>
> Key: HBASE-21007
> URL: https://issues.apache.org/jira/browse/HBASE-21007
> Project: HBase
> Issue Type: Bug
> Components: REST
>Affects Versions: 1.4.0, 1.4.6
>Reporter: Bosko Devetak
>Assignee: Bosko Devetak
>Priority: Critical
> Fix For: 3.0.0, 1.5.0, 1.2.7, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-21007.001.patch, HBASE-21007.002.patch
>
>
> When using the URIs like this:
>
> /sometable/*?limit=$limit&startrow=$startrow&endrow=$endrow
>
> where *$limit* is smaller than the range between *$startrow* and *$endrow*,
> the rest server will start leaking memory.
>
>
> The bug is in the *TableScanResource.java* class. Basically, the
> ResultScanner is not being closed in next() method when the limit has been
> reached.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[
https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16573964#comment-16573964
]
Hadoop QA commented on HBASE-21027:
---
| (x) *{color:red}-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:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}
0m 0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
19s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
41s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
30s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
17s{color} | {color:green} hbase-server: The patch generated 0 new + 1
unchanged - 1 fixed = 1 total (was 2) {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} shadedjars {color} | {color:green} 4m
54s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
11m 17s{color} | {color:green} Patch does not cause any errors with Hadoop
2.7.4 or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
37s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}113m 10s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
20s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 2s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.io.hfile.bucket.TestBucketCache |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21027 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934866/HBASE-21027.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux c7d44eb2fdc8 3.13.0-143-generic #192-Ubuntu SMP Tue Feb 27
10:45:36 UTC 2018 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 / 3f5033f88e |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_171 |
| findbugs | v3.1.0-RC3 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/13985/artifact/patchprocess/patch-unit-hbase-server.
[jira] [Created] (HBASE-21028) Backport HBASE-18633 to branch-1.3
Daniel Wong created HBASE-21028: --- Summary: Backport HBASE-18633 to branch-1.3 Key: HBASE-21028 URL: https://issues.apache.org/jira/browse/HBASE-21028 Project: HBase Issue Type: Improvement Components: regionserver Affects Versions: 1.3.2 Reporter: Daniel Wong Fix For: 1.3.3 The logging improvements in HBASE-18633 would give greater visibility on systems in 1.3. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[
https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574064#comment-16574064
]
Sean Busbey edited comment on HBASE-21027 at 8/9/18 12:27 AM:
--
the test failures are because of the collector:
{code}
68 // No synchronization here because weakly consistent view should be
good enough
69 return registeredDeserializers.entrySet().stream()
70 .collect(Collectors.toMap(Map.Entry::getKey, v ->
v.getClass().getName()));
{code}
the value mapper function takes a Map.Entry as a parameter, so we store the
fqcn for Map.Entry over and over. should be {{entry ->
entry.getValue().getClass().getName()}} I think?
was (Author: busbey):
the test failures are because of the collector:
{code}
68 // No synchronization here because weakly consistent view should be
good enough
69 return registeredDeserializers.entrySet().stream()
70 .collect(Collectors.toMap(Map.Entry::getKey, v ->
v.getClass().getName()));
{code}
the value mapper function takes a Map.Entry as a value, so we store the fqcn
for Map.Entry over and over. should be {{entry ->
entry.getValue().getClass().getName()}} I think?
> Inconsistent synchronization in CacheableDeserializerIdManager
> ---
>
> Key: HBASE-21027
> URL: https://issues.apache.org/jira/browse/HBASE-21027
> Project: HBase
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21027.master.001.patch
>
>
> There is some inconsistent synchronization going on in CDIM, we should switch
> it to using ConcurrentHashMap and simplify our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[
https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574064#comment-16574064
]
Sean Busbey commented on HBASE-21027:
-
the test failures are because of the collector:
{code}
68 // No synchronization here because weakly consistent view should be
good enough
69 return registeredDeserializers.entrySet().stream()
70 .collect(Collectors.toMap(Map.Entry::getKey, v ->
v.getClass().getName()));
{code}
the value mapper function takes a Map.Entry as a value, so we store the fqcn
for Map.Entry over and over. should be {{entry ->
entry.getValue().getClass().getName()}} I think?
> Inconsistent synchronization in CacheableDeserializerIdManager
> ---
>
> Key: HBASE-21027
> URL: https://issues.apache.org/jira/browse/HBASE-21027
> Project: HBase
> Issue Type: Task
>Affects Versions: 3.0.0
>Reporter: Mike Drob
>Assignee: Mike Drob
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-21027.master.001.patch
>
>
> There is some inconsistent synchronization going on in CDIM, we should switch
> it to using ConcurrentHashMap and simplify our code.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574169#comment-16574169 ] Mike Drob commented on HBASE-21027: --- Yep, my bad. Fixed in v2. Also elaborated more on the comment. > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch, > HBASE-21027.master.002.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21027) Inconsistent synchronization in CacheableDeserializerIdManager
[ https://issues.apache.org/jira/browse/HBASE-21027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-21027: -- Attachment: HBASE-21027.master.002.patch > Inconsistent synchronization in CacheableDeserializerIdManager > --- > > Key: HBASE-21027 > URL: https://issues.apache.org/jira/browse/HBASE-21027 > Project: HBase > Issue Type: Task >Affects Versions: 3.0.0 >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-21027.master.001.patch, > HBASE-21027.master.002.patch > > > There is some inconsistent synchronization going on in CDIM, we should switch > it to using ConcurrentHashMap and simplify our code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20985) add two attributes when we do normalization
[ https://issues.apache.org/jira/browse/HBASE-20985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574188#comment-16574188 ] Guanghao Zhang commented on HBASE-20985: +1. Ping [~Apache9] for branch-2.1 and ping [~stack] for branch-2.0. > add two attributes when we do normalization > --- > > Key: HBASE-20985 > URL: https://issues.apache.org/jira/browse/HBASE-20985 > Project: HBase > Issue Type: Improvement >Affects Versions: 2.1.0 >Reporter: Jingyun Tian >Assignee: Jingyun Tian >Priority: Major > Fix For: 2.1.0 > > Attachments: HBASE-20985.master.001.patch, > HBASE-20985.master.002.patch, HBASE-20985.master.003.patch, > HBASE-20985.master.004.patch, HBASE-20985.master.005.patch > > > Currently when we turn on normalization switch, it will help balance the > whole table based on total region size / total region count. I add two > attributes so that we can set total region count or average region size we > want to achieve when normalization done. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-21012) Revert the change of serializing TimeRangeTracker
[
https://issues.apache.org/jira/browse/HBASE-21012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574192#comment-16574192
]
Kuan-Po Tseng commented on HBASE-21012:
---
Josh Elser Thanks for your comments.
{quote}I'd suggest just including an HFile with the old serialization and
including it in src/test/resources. Then, you just write a test to make sure it
can read that old HFile version.
{quote}
HBase in 2.x are capable of reading HFile from old version, the problem is old
HBase version can't read HFile generated by new HBase version. So we have to
revert the way of serializing TRT. (This situation might not be called as
"backward compatability", sorry about that.)
> Revert the change of serializing TimeRangeTracker
> -
>
> Key: HBASE-21012
> URL: https://issues.apache.org/jira/browse/HBASE-21012
> Project: HBase
> Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Kuan-Po Tseng
>Priority: Critical
> Fix For: 3.0.0, 2.0.2, 2.1.1
>
> Attachments: HBASE-21012.master.001.patch,
> HBASE-21012.master.002.patch, HBASE-21012.master.003.patch,
> HBASE-21012.master.003.patch, HBASE-21012.master.004.patch
>
>
> HBASE-18754 change the serialization of TimeRangeTracker from "manual way" to
> protobuf. However, the change breaks the backward compatibility of hfile. We
> should revert the change ASAP.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20972) Fix call queue buffer size leaking bug
[ https://issues.apache.org/jira/browse/HBASE-20972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20972: --- Attachment: HBASE-20972.branch-2.0.002.patch > Fix call queue buffer size leaking bug > -- > > Key: HBASE-20972 > URL: https://issues.apache.org/jira/browse/HBASE-20972 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20972.branch-2.0.001.patch, > HBASE-20972.branch-2.0.002.patch, HBASE-20972.master.001.patch > > > Call queue size is the currently queued and running Calls bytes size. It gets > incremented after we parse a call and before we add it to the queue of calls > for the scheduler to use. It get decremented after we have 'run' the Call. > When setting up a call, total size of it is added. So when a new call can not > be dispatched by BlockingQueue full, the call queue size should be > decremented. We shouldn't add size of rejected calls to the call queue size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20972) Fix call queue buffer size leaking bug
[ https://issues.apache.org/jira/browse/HBASE-20972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaolin Ha updated HBASE-20972: --- Attachment: HBASE-20972.master.002.patch > Fix call queue buffer size leaking bug > -- > > Key: HBASE-20972 > URL: https://issues.apache.org/jira/browse/HBASE-20972 > Project: HBase > Issue Type: Bug > Components: IPC/RPC >Affects Versions: 2.1.0, 2.0.0, 2.2.0 >Reporter: Xiaolin Ha >Assignee: Xiaolin Ha >Priority: Major > Attachments: HBASE-20972.branch-2.0.001.patch, > HBASE-20972.branch-2.0.002.patch, HBASE-20972.master.001.patch, > HBASE-20972.master.002.patch > > > Call queue size is the currently queued and running Calls bytes size. It gets > incremented after we parse a call and before we add it to the queue of calls > for the scheduler to use. It get decremented after we have 'run' the Call. > When setting up a call, total size of it is added. So when a new call can not > be dispatched by BlockingQueue full, the call queue size should be > decremented. We shouldn't add size of rejected calls to the call queue size. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-21025) Add cache for TableStateManager
[ https://issues.apache.org/jira/browse/HBASE-21025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-21025: -- Attachment: HBASE-21025-v1.patch > Add cache for TableStateManager > --- > > Key: HBASE-21025 > URL: https://issues.apache.org/jira/browse/HBASE-21025 > Project: HBase > Issue Type: Sub-task >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-21025-v1.patch, HBASE-21025.patch > > > After HBASE-20881, we will check whether a table is disabled in SCP, so we > need to add cache for it to improve MTTR, and also reduce the request to meta. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20965) Separate region server report requests to new handlers
[ https://issues.apache.org/jira/browse/HBASE-20965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16574206#comment-16574206 ] Yu Li commented on HBASE-20965: --- Creation/Link of new JIRA about better handler utilization and release note here please. Thanks. > Separate region server report requests to new handlers > -- > > Key: HBASE-20965 > URL: https://issues.apache.org/jira/browse/HBASE-20965 > Project: HBase > Issue Type: Improvement > Components: Performance >Reporter: Yi Mei >Assignee: Yi Mei >Priority: Major > Fix For: 3.0.0, 2.2.0 > > Attachments: HBASE-20965.master.001.patch, > HBASE-20965.master.002.patch, HBASE-20965.master.003.patch, > HBASE-20965.master.004.patch, HBASE-20965.master.005.patch, > HBASE-20965.master.006.patch, HBASE-20965.master.007.patch, > HBASE-20965.master.008.patch, HBASE-20965.master.009.patch, > HBASE-20965.master.010.patch, HBASE-20965.master.011.patch > > > In master rpc scheduler, all rpc requests are executed in a thread pool. This > task separates rs report requests to new handlers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
