[jira] [Commented] (HBASE-13389) [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
[
https://issues.apache.org/jira/browse/HBASE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566424#comment-16566424
]
Anoop Sam John commented on HBASE-13389:
I think so.. So looks like now we tend to keep this mvcc for really longer.
One or the other reason.
Can we make it such that we keep the mvcc in long format rather than vlong?
As it is vlong, every cell read need to read the vlong byte by byte and causing
perf. For random read, the seek need to skip many cells.
> [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
> -
>
> Key: HBASE-13389
> URL: https://issues.apache.org/jira/browse/HBASE-13389
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
>Reporter: stack
>Priority: Major
> Attachments: 13389.txt
>
>
> HBASE-12600 moved the edit sequenceid from tags to instead exploit the
> mvcc/sequenceid slot in a key. Now Cells near-always have an associated
> mvcc/sequenceid where previous it was rare or the mvcc was kept up at the
> file level. This is sort of how it should be many of us would argue but as a
> side-effect of this change, read-time optimizations that helped speed scans
> were undone by this change.
> In this issue, lets see if we can get the optimizations back -- or just
> remove the optimizations altogether.
> The parse of mvcc/sequenceid is expensive. It was noticed over in HBASE-13291.
> The optimizations undone by this changes are (to quote the optimizer himself,
> Mr [~lhofhansl]):
> {quote}
> Looks like this undoes all of HBASE-9751, HBASE-8151, and HBASE-8166.
> We're always storing the mvcc readpoints, and we never compare them against
> the actual smallestReadpoint, and hence we're always performing all the
> checks, tests, and comparisons that these jiras removed in addition to
> actually storing the data - which with up to 8 bytes per Cell is not trivial.
> {quote}
> This is the 'breaking' change:
> https://github.com/apache/hbase/commit/2c280e62530777ee43e6148fd6fcf6dac62881c0#diff-07c7ac0a9179cedff02112489a20157fR96
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-17519) Rollback the removed cells
[ https://issues.apache.org/jira/browse/HBASE-17519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566376#comment-16566376 ] Nihal Jain commented on HBASE-17519: I think this should go in branch-1.3 and others as well. Ping [~apurtell] > Rollback the removed cells > -- > > Key: HBASE-17519 > URL: https://issues.apache.org/jira/browse/HBASE-17519 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Major > Fix For: 1.4.0 > > Attachments: HBASE-17519.branch-1.v0.patch, > HBASE-17519.branch-1.v1.patch, HBASE-17519.branch-1.v1.patch, > HBASE-17519.branch-1.v2.patch, HBASE-17519.branch-1.v2.patch, > HBASE-17519.branch-1.v2.patch > > > The Store#upsert removes the old cells but we don’t rollback the removed > cells when failing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[
https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566371#comment-16566371
]
Hudson commented on HBASE-20856:
Results for branch branch-2.1
[build #133 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/133/]:
(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/133//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/133//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/133//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> PITA having to set WAL provider in two places
> -
>
> Key: HBASE-20856
> URL: https://issues.apache.org/jira/browse/HBASE-20856
> Project: HBase
> Issue Type: Improvement
> Components: Operability, wal
>Affects Versions: 3.0.0
>Reporter: stack
>Assignee: Tak Lon (Stephen) Wu
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20856.branch-2.001.patch,
> HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch,
> HBASE-20856.master.002.patch, HBASE-20856.master.003.patch
>
>
> Courtesy of [~elserj], I learn that changing WAL we need to set two places...
> both hbase.wal.meta_provider and hbase.wal.provider. Operator should only
> have to set it in one place; hbase.wal.meta_provider should pick up general
> setting unless hbase.wal.meta_provider is explicitly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20986) Separate the config of block size when we do log splitting and write Hlog
[
https://issues.apache.org/jira/browse/HBASE-20986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566360#comment-16566360
]
Hadoop QA commented on HBASE-20986:
---
| (/) *{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} 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
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
52s{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
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
35s{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
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
44s{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 12s{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:green}+1{color} | {color:green} unit {color} | {color:green}116m
3s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
23s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}158m 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-20986 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12934005/HBASE-20986.master.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux e679bc644d71 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 4bcaf495c2 |
| 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/13892/testReport/ |
| Max. process+thread count | 4344 (vs. ulimit of 1) |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Buil
[jira] [Updated] (HBASE-20987) Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in master startup
[ https://issues.apache.org/jira/browse/HBASE-20987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20987: -- Attachment: HBASE-20987.branch-2.0.003.patch > Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in > master startup > -- > > Key: HBASE-20987 > URL: https://issues.apache.org/jira/browse/HBASE-20987 > Project: HBase > Issue Type: Bug > Components: amv2 >Affects Versions: 2.0.1 >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.2 > > Attachments: HBASE-20987.branch-2.0.001.patch, > HBASE-20987.branch-2.0.002.patch, HBASE-20987.branch-2.0.003.patch > > > Evaluate whether to backport HBASE-20708 Remove the usage of > RecoverMetaProcedure in master startup. Its a radical patch. Too radical for > a point release? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20987) Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in master startup
[ https://issues.apache.org/jira/browse/HBASE-20987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20987: -- Attachment: HBASE-20987.branch-2.0.002.patch > Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in > master startup > -- > > Key: HBASE-20987 > URL: https://issues.apache.org/jira/browse/HBASE-20987 > Project: HBase > Issue Type: Bug > Components: amv2 >Affects Versions: 2.0.1 >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.2 > > Attachments: HBASE-20987.branch-2.0.001.patch, > HBASE-20987.branch-2.0.002.patch, HBASE-20987.branch-2.0.003.patch > > > Evaluate whether to backport HBASE-20708 Remove the usage of > RecoverMetaProcedure in master startup. Its a radical patch. Too radical for > a point release? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20969) Create an hbase-operator-tools repo to host hbck2 and later, other toolings
[ https://issues.apache.org/jira/browse/HBASE-20969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566358#comment-16566358 ] stack commented on HBASE-20969: --- bq. was that intentional? INFRA sent me there. See INFRA-16847 (Outstanding questions). Yeah, on the PR but we'd just do traditional flow. Meantime, we could play around w/ the new setup. These new repos are siloed-off from core so good place for experiment. > Create an hbase-operator-tools repo to host hbck2 and later, other toolings > --- > > Key: HBASE-20969 > URL: https://issues.apache.org/jira/browse/HBASE-20969 > Project: HBase > Issue Type: Sub-task > Components: hbck2 >Affects Versions: 2.0.1 >Reporter: stack >Priority: Major > > Let me make a new repo to host hbck2 and any other operator tools that make > sense to break off from core. > See the discusion thread on dev [1] that blesses this project. > 1. > http://apache-hbase.679495.n3.nabble.com/DISCUSS-Separate-Git-Repository-for-HBCK2-td4096319.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20550) Document about MasterProcWAL
[ https://issues.apache.org/jira/browse/HBASE-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566351#comment-16566351 ] Daisuke Kobayashi commented on HBASE-20550: --- Thanks [~stack]! Email address may not be visible while I'm setting it in my profile. > Document about MasterProcWAL > > > Key: HBASE-20550 > URL: https://issues.apache.org/jira/browse/HBASE-20550 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Daisuke Kobayashi >Assignee: Daisuke Kobayashi >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20550.master.001.patch, HBASE-20550.patch > > > Lack of contents about MasterProcWAL even it has been present since 1.x > release. I just did a small write-up and appreciate if experts could review > it. > One thing I'm missing is: how to troubleshoot a case once the WAL file gets > increased in size abruptly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[
https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566343#comment-16566343
]
Hudson commented on HBASE-20856:
Results for branch branch-2
[build #1055 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1055/]:
(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/1055//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/1055//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/1055//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> PITA having to set WAL provider in two places
> -
>
> Key: HBASE-20856
> URL: https://issues.apache.org/jira/browse/HBASE-20856
> Project: HBase
> Issue Type: Improvement
> Components: Operability, wal
>Affects Versions: 3.0.0
>Reporter: stack
>Assignee: Tak Lon (Stephen) Wu
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20856.branch-2.001.patch,
> HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch,
> HBASE-20856.master.002.patch, HBASE-20856.master.003.patch
>
>
> Courtesy of [~elserj], I learn that changing WAL we need to set two places...
> both hbase.wal.meta_provider and hbase.wal.provider. Operator should only
> have to set it in one place; hbase.wal.meta_provider should pick up general
> setting unless hbase.wal.meta_provider is explicitly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[
https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566335#comment-16566335
]
Hudson commented on HBASE-20856:
Results for branch branch-2.0
[build #621 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/621/]:
(/) *{color:green}+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.0/621//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/621//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/621//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> PITA having to set WAL provider in two places
> -
>
> Key: HBASE-20856
> URL: https://issues.apache.org/jira/browse/HBASE-20856
> Project: HBase
> Issue Type: Improvement
> Components: Operability, wal
>Affects Versions: 3.0.0
>Reporter: stack
>Assignee: Tak Lon (Stephen) Wu
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20856.branch-2.001.patch,
> HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch,
> HBASE-20856.master.002.patch, HBASE-20856.master.003.patch
>
>
> Courtesy of [~elserj], I learn that changing WAL we need to set two places...
> both hbase.wal.meta_provider and hbase.wal.provider. Operator should only
> have to set it in one place; hbase.wal.meta_provider should pick up general
> setting unless hbase.wal.meta_provider is explicitly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20885) Remove entry for RPC quota from hbase:quota when RPC quota is removed.
[
https://issues.apache.org/jira/browse/HBASE-20885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566329#comment-16566329
]
Sakthi commented on HBASE-20885:
[~elserj] I have updated the patch. Please review.
> Remove entry for RPC quota from hbase:quota when RPC quota is removed.
> --
>
> Key: HBASE-20885
> URL: https://issues.apache.org/jira/browse/HBASE-20885
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: hbase-20885.master.001.patch,
> hbase-20885.master.002.patch, hbase-20885.master.003.patch,
> hbase-20885.master.003.patch, hbase-20885.master.004.patch,
> hbase-20885.master.005.patch
>
>
> When a RPC quota is removed (using LIMIT => 'NONE'), the entry from
> hbase:quota table is not completely removed. For e.g. see below:
> {noformat}
> hbase(main):005:0> create 't2','cf1'
> Created table t2
> Took 0.8000 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.1024 seconds
> hbase(main):007:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0622 seconds
> hbase(main):008:0> scan 'hbase:quota'
> ROWCOLUMN+CELL
> t.t2 column=q:s, timestamp=1531513014463,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80
>\x05 \x02
> 1 row(s)
> Took 0.0453 seconds
> hbase(main):009:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT => 'NONE'
> Took 0.0097 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> 0 row(s)
> Took 0.0338 seconds
> hbase(main):011:0> scan 'hbase:quota'
> ROWCOLUMN+CELL
> t.t2 column=q:s, timestamp=1531513039505,
> value=PBUF\x12\x00
> 1 row(s)
> Took 0.0066 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20885) Remove entry for RPC quota from hbase:quota when RPC quota is removed.
[
https://issues.apache.org/jira/browse/HBASE-20885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sakthi updated HBASE-20885:
---
Attachment: hbase-20885.master.005.patch
> Remove entry for RPC quota from hbase:quota when RPC quota is removed.
> --
>
> Key: HBASE-20885
> URL: https://issues.apache.org/jira/browse/HBASE-20885
> Project: HBase
> Issue Type: Sub-task
>Reporter: Sakthi
>Assignee: Sakthi
>Priority: Minor
> Attachments: hbase-20885.master.001.patch,
> hbase-20885.master.002.patch, hbase-20885.master.003.patch,
> hbase-20885.master.003.patch, hbase-20885.master.004.patch,
> hbase-20885.master.005.patch
>
>
> When a RPC quota is removed (using LIMIT => 'NONE'), the entry from
> hbase:quota table is not completely removed. For e.g. see below:
> {noformat}
> hbase(main):005:0> create 't2','cf1'
> Created table t2
> Took 0.8000 seconds
> => Hbase::Table - t2
> hbase(main):006:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT =>
> '10M/sec'
> Took 0.1024 seconds
> hbase(main):007:0> list_quotas
> OWNER QUOTAS
> TABLE => t2 TYPE => THROTTLE, THROTTLE_TYPE =>
> REQUEST_SIZE, LIMIT => 10M/sec, SCOPE => MACHINE
> 1 row(s)
> Took 0.0622 seconds
> hbase(main):008:0> scan 'hbase:quota'
> ROWCOLUMN+CELL
> t.t2 column=q:s, timestamp=1531513014463,
> value=PBUF\x12\x0B\x12\x09\x08\x04\x10\x80\x80\x80
>\x05 \x02
> 1 row(s)
> Took 0.0453 seconds
> hbase(main):009:0> set_quota TYPE => THROTTLE, TABLE => 't2', LIMIT => 'NONE'
> Took 0.0097 seconds
> hbase(main):010:0> list_quotas
> OWNER QUOTAS
> 0 row(s)
> Took 0.0338 seconds
> hbase(main):011:0> scan 'hbase:quota'
> ROWCOLUMN+CELL
> t.t2 column=q:s, timestamp=1531513039505,
> value=PBUF\x12\x00
> 1 row(s)
> Took 0.0066 seconds
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20937) Update the support matrix in our ref guide about the recent hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566320#comment-16566320 ] stack commented on HBASE-20937: --- NP. Reverted and pushed the below. commit 78164efcf461ab22df1fe153460c435deb2e1011 (HEAD -> m, origin/master, origin/HEAD) Author: Michael Stack Date: Wed Aug 1 21:07:37 2018 -0700 Revert "HBASE-20937 Update the support matrix in our ref guide about recent hadoop releases" Revert. Need discuss on mailing list first. This reverts commit 1b28903b7bd8717f2d653eeb48528a31e0add29c. > Update the support matrix in our ref guide about the recent hadoop releases > --- > > Key: HBASE-20937 > URL: https://issues.apache.org/jira/browse/HBASE-20937 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > > > Copied from HBASE-20538 "Upgrade our hadoop versions to 2.7.7 and 3.0.3" and > from HBASE-20970 > Apache9 Duo Zhang added a comment - 6 days ago > I think we should mark 2.7.x before 2.7.7 as 'Not Supported' due to the JDK > issue? We only support jdk8 for 2.0 or above. > Apache9 Duo Zhang added a comment - 6 days ago - Restricted to Committers > And IIRC there is a security issue before 2.7.7 so it is important to drop > the support and let users upgrade to 2.7.7? > Apache9 Duo Zhang added a comment - 6 days ago > Also upgrade hadoop3 dependency to 3.0.3 which contains HADOOP-15473. > How does this issue relate to HBASE-20937? > Do we support 3.0.3 now? > Actually no. We do not support any 3.0.x releases due to the YARN issue > YARN-7190. But at least it could let us add back the ignored security UT. > There is still no production ready 3.1.x release... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20886) [Auth] Support keytab login in hbase client
[
https://issues.apache.org/jira/browse/HBASE-20886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566312#comment-16566312
]
Reid Chan commented on HBASE-20886:
---
bq. One open thought: how does this play with MapReduce code where we are
connecting to HBase via delegation-tokens instead of real Kerberos credentials?
Sorry Josh, you mentioned once, it was my oversight..
Will be back with demo results. [~elserj]
> [Auth] Support keytab login in hbase client
> ---
>
> Key: HBASE-20886
> URL: https://issues.apache.org/jira/browse/HBASE-20886
> Project: HBase
> Issue Type: New Feature
> Components: asyncclient, Client, security
>Reporter: Reid Chan
>Assignee: Reid Chan
>Priority: Critical
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-20886.master.001.patch,
> HBASE-20886.master.002.patch, HBASE-20886.master.003.patch,
> HBASE-20886.master.004.patch, HBASE-20886.master.005.patch,
> HBASE-20886.master.006.patch, HBASE-20886.master.007.patch,
> HBASE-20886.master.008.patch
>
>
> There're lots of questions about how to connect to kerberized hbase cluster
> through hbase-client api from user-mail and slack channel.
> {{hbase.client.keytab.file}} and {{hbase.client.keytab.principal}} are
> already existed in code base, but they are only used in {{Canary}}.
> This issue is to make use of two configs to support client-side keytab based
> login, after this issue resolved, hbase-client should directly connect to
> kerberized cluster without changing any code as long as
> {{hbase.client.keytab.file}} and {{hbase.client.keytab.principal}} are
> specified.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20987) Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in master startup
[
https://issues.apache.org/jira/browse/HBASE-20987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566290#comment-16566290
]
Hadoop QA commented on HBASE-20987:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
15s{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} branch-2.0 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
45s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
10s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
19s{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
41s{color} | {color:green} branch-2.0 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} branch-2.0 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 1m
51s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
28s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 28s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} hbase-procedure: The patch generated 0 new + 1
unchanged - 5 fixed = 1 total (was 6) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} hbase-server: The patch generated 0 new + 26
unchanged - 1 fixed = 26 total (was 27) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
50s{color} | {color:red} patch has 53 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m
51s{color} | {color:red} The patch causes 53 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
35s{color} | {color:red} The patch causes 53 errors with Hadoop v2.7.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
27s{color} | {color:red} The patch causes 53 errors with Hadoop v3.0.0. {color}
|
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
30s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
29s{color} | {color:red} hbase-server generated 1 new + 1 unchanged - 0 fixed =
2 total (was 1) {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
44s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 0m 32s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 34m 17s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-20987 |
| JIRA Pat
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566287#comment-16566287 ] Sean Busbey commented on HBASE-20856: - yeah that section does a good job of covering the limitations of GitHub PRs currently: http://hbase.apache.org/book.html#_close_related_github_prs QABot should work with PRs though, so long as you attach a link to the PR and put jira into Patch Available status. If it doesn't then please point me at the issue before finding a work around. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[
https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566285#comment-16566285
]
Reid Chan commented on HBASE-20856:
---
PR is not integrated with QA bot, please stop using PR anymore [~taklwu].
There is section about {{Close related GitHub PRs}} in book [ref
book|http://hbase.apache.org/book.html]. But i think Sean knows more and better.
> PITA having to set WAL provider in two places
> -
>
> Key: HBASE-20856
> URL: https://issues.apache.org/jira/browse/HBASE-20856
> Project: HBase
> Issue Type: Improvement
> Components: Operability, wal
>Affects Versions: 3.0.0
>Reporter: stack
>Assignee: Tak Lon (Stephen) Wu
>Priority: Minor
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20856.branch-2.001.patch,
> HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch,
> HBASE-20856.master.002.patch, HBASE-20856.master.003.patch
>
>
> Courtesy of [~elserj], I learn that changing WAL we need to set two places...
> both hbase.wal.meta_provider and hbase.wal.provider. Operator should only
> have to set it in one place; hbase.wal.meta_provider should pick up general
> setting unless hbase.wal.meta_provider is explicitly set.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20969) Create an hbase-operator-tools repo to host hbck2 and later, other toolings
[ https://issues.apache.org/jira/browse/HBASE-20969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566282#comment-16566282 ] Sean Busbey commented on HBASE-20969: - saw the notices for gitbox repos for these. was that intentional? being in gitbox instead of the standard ASF infra means we'll be able to directly merge PRs and close PRs/issues from the github interface, but that encourages a very different workflow from what we do in the rest of the project. I worry about having to maintain multiple guides on "how to contribute" when we're behind on maintaining the one we have. > Create an hbase-operator-tools repo to host hbck2 and later, other toolings > --- > > Key: HBASE-20969 > URL: https://issues.apache.org/jira/browse/HBASE-20969 > Project: HBase > Issue Type: Sub-task > Components: hbck2 >Affects Versions: 2.0.1 >Reporter: stack >Priority: Major > > Let me make a new repo to host hbck2 and any other operator tools that make > sense to break off from core. > See the discusion thread on dev [1] that blesses this project. > 1. > http://apache-hbase.679495.n3.nabble.com/DISCUSS-Separate-Git-Repository-for-HBCK2-td4096319.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (HBASE-20937) Update the support matrix in our ref guide about the recent hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reopened HBASE-20937: - > Update the support matrix in our ref guide about the recent hadoop releases > --- > > Key: HBASE-20937 > URL: https://issues.apache.org/jira/browse/HBASE-20937 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > > > Copied from HBASE-20538 "Upgrade our hadoop versions to 2.7.7 and 3.0.3" and > from HBASE-20970 > Apache9 Duo Zhang added a comment - 6 days ago > I think we should mark 2.7.x before 2.7.7 as 'Not Supported' due to the JDK > issue? We only support jdk8 for 2.0 or above. > Apache9 Duo Zhang added a comment - 6 days ago - Restricted to Committers > And IIRC there is a security issue before 2.7.7 so it is important to drop > the support and let users upgrade to 2.7.7? > Apache9 Duo Zhang added a comment - 6 days ago > Also upgrade hadoop3 dependency to 3.0.3 which contains HADOOP-15473. > How does this issue relate to HBASE-20937? > Do we support 3.0.3 now? > Actually no. We do not support any 3.0.x releases due to the YARN issue > YARN-7190. But at least it could let us add back the ignored security UT. > There is still no production ready 3.1.x release... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (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=16566276#comment-16566276 ] Guanghao Zhang edited comment on HBASE-20985 at 8/2/18 2:51 AM: bq. masterServices.getTableDescriptors().get(table) The returned tableDesc may be null? was (Author: zghaobac): bq. masterServices.getTableDescriptors().get(table) The return tableDesc may be null? > 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 > > > 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-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=16566276#comment-16566276 ] Guanghao Zhang commented on HBASE-20985: bq. masterServices.getTableDescriptors().get(table) The return tableDesc may be null? > 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 > > > 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-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=16566275#comment-16566275 ] Guanghao Zhang commented on HBASE-20985: Add a unit test for hbase-shell? > 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 > > > 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-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=16566274#comment-16566274 ] Jingyun Tian commented on HBASE-20985: -- [~yuzhih...@gmail.com] Sure. Thank you all the same. > 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 > > > 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-20937) Update the support matrix in our ref guide about the recent hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566271#comment-16566271 ] Sean Busbey commented on HBASE-20937: - please revert. marking a bunch of Hadoop releases as X should have a dev@ DISCUSS thread. Hadoop has had a ton of CVEs over the years and we've never unilaterally moved versions to X because of it before. > Update the support matrix in our ref guide about the recent hadoop releases > --- > > Key: HBASE-20937 > URL: https://issues.apache.org/jira/browse/HBASE-20937 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > > > Copied from HBASE-20538 "Upgrade our hadoop versions to 2.7.7 and 3.0.3" and > from HBASE-20970 > Apache9 Duo Zhang added a comment - 6 days ago > I think we should mark 2.7.x before 2.7.7 as 'Not Supported' due to the JDK > issue? We only support jdk8 for 2.0 or above. > Apache9 Duo Zhang added a comment - 6 days ago - Restricted to Committers > And IIRC there is a security issue before 2.7.7 so it is important to drop > the support and let users upgrade to 2.7.7? > Apache9 Duo Zhang added a comment - 6 days ago > Also upgrade hadoop3 dependency to 3.0.3 which contains HADOOP-15473. > How does this issue relate to HBASE-20937? > Do we support 3.0.3 now? > Actually no. We do not support any 3.0.x releases due to the YARN issue > YARN-7190. But at least it could let us add back the ignored security UT. > There is still no production ready 3.1.x release... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20986) Separate the config of block size when we do log splitting and write Hlog
[ https://issues.apache.org/jira/browse/HBASE-20986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jingyun Tian updated HBASE-20986: - Attachment: HBASE-20986.master.002.patch > Separate the config of block size when we do log splitting and write Hlog > - > > Key: HBASE-20986 > URL: https://issues.apache.org/jira/browse/HBASE-20986 > 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-20986.master.001.patch, > HBASE-20986.master.002.patch > > > Since the block size of recovered edits and hlog are the same right now, if > we set a large value to block size, name node may not able to assign enough > space when we do log splitting. But set a large value to hlog block size can > help reduce the number of region server asking for a new block. Thus I think > separate the config of block size is necessary. -- 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=16566268#comment-16566268 ] Ted Yu commented on HBASE-20985: I may not have time to do a thorough review. You can ask other committers to review. thanks > 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 > > > 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-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566264#comment-16566264 ] Mike Drob commented on HBASE-20856: --- PRs are also automatically closed if there is a commit (on master only?) with "fixes #xxx" in the text. Also closes or a few other magic words but I don't remember what they are. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- 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=16566247#comment-16566247 ] Jingyun Tian commented on HBASE-20985: -- [~yuzhih...@gmail.com] New patch uploaded. Could you help check it out? > 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 > > > 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-20987) Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in master startup
[ https://issues.apache.org/jira/browse/HBASE-20987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20987: -- Status: Patch Available (was: Open) .0001 is cherry-pick of with minor fixup: 8eab6d7a45 HBASE-20847 Addendum use addFront instead of addBack to add sub procedure 113652eb88 HBASE-20847 The parent procedure of RegionTransitionProcedure may not have the table lock > Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in > master startup > -- > > Key: HBASE-20987 > URL: https://issues.apache.org/jira/browse/HBASE-20987 > Project: HBase > Issue Type: Bug > Components: amv2 >Affects Versions: 2.0.1 >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.2 > > Attachments: HBASE-20987.branch-2.0.001.patch > > > Evaluate whether to backport HBASE-20708 Remove the usage of > RecoverMetaProcedure in master startup. Its a radical patch. Too radical for > a point release? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20987) Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in master startup
[ https://issues.apache.org/jira/browse/HBASE-20987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20987: -- Attachment: HBASE-20987.branch-2.0.001.patch > Evalate backport of HBASE-20708 Remove the usage of RecoverMetaProcedure in > master startup > -- > > Key: HBASE-20987 > URL: https://issues.apache.org/jira/browse/HBASE-20987 > Project: HBase > Issue Type: Bug > Components: amv2 >Affects Versions: 2.0.1 >Reporter: stack >Assignee: stack >Priority: Major > Fix For: 2.0.2 > > Attachments: HBASE-20987.branch-2.0.001.patch > > > Evaluate whether to backport HBASE-20708 Remove the usage of > RecoverMetaProcedure in master startup. Its a radical patch. Too radical for > a point release? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566198#comment-16566198 ] stack commented on HBASE-20856: --- I don't know [~zyork] Perhaps someone else knows. I see that the new repos we've added, hbase-connectors and hbase-operator-tools, are in apache gitbox which is github hosted and I had to connect my apache and github profiles (after being added to the asf group). Perhaps then it'll be possible for committers to close out PRs? > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20978) [amv2] Worker terminating UNNATURALLY during MoveRegionProcedure
[
https://issues.apache.org/jira/browse/HBASE-20978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566181#comment-16566181
]
stack commented on HBASE-20978:
---
Dang. Just ran into this again. This time around a split. Killed my big ITBLL
job because the split procedure is not finished...the parent is offlined but
the daughters are never onlined..
{code}
2018-08-01 15:04:35,270 INFO [PEWorker-11] procedure.MasterProcedureScheduler:
pid=136, state=WAITING:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS;
SplitTableRegionProcedure table=IntegrationTestBigLinkedList,
parent=ffe6b658f9f454d05666519a056561ed,
daughterA=e46894098b487301d7bceb5b60e5c75a,
daughterB=0d53dd4eac9c9e21d8c1af4cd6c8ac31 checking lock on
ffe6b658f9f454d05666519a056561ed
2018-08-01 15:04:35,270 WARN [PEWorker-11] procedure2.ProcedureExecutor:
Worker terminating UNNATURALLY null
java.lang.IllegalArgumentException: state=WAITING pid=136,
state=WAITING:SPLIT_TABLE_REGIONS_CHECK_CLOSED_REGIONS;
SplitTableRegionProcedure table=IntegrationTestBigLinkedList,
parent=ffe6b658f9f454d05666519a056561ed,
daughterA=e46894098b487301d7bceb5b60e5c75a,
daughterB=0d53dd4eac9c9e21d8c1af4cd6c8ac31
at
org.apache.hbase.thirdparty.com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1458)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1249)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$900(ProcedureExecutor.java:76)
at
org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1763)
{code}
Will dig in.
> [amv2] Worker terminating UNNATURALLY during MoveRegionProcedure
>
>
> Key: HBASE-20978
> URL: https://issues.apache.org/jira/browse/HBASE-20978
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.1
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 2.0.2
>
>
> Testing tip of branch-2.0, ran into this:
> {code}
> 2018-07-29 01:45:33,002 INFO [master/ve0524:16000] master.HMaster: Master
> has completed initialization 13.854sec
>2018-07-29
> 01:45:33,003 INFO [PEWorker-4] procedure.MasterProcedureScheduler: pid=1820,
> state=WAITING:MOVE_REGION_ASSIGN; MoveRegionProcedure
> hri=533fb79ba23b27e9e0715b51daeb30c1,
> source=ve0538.halxg.cloudera.com,16020,1532847421672,
> destination=ve0540.halxg.cloudera.com,16020,1532853151031 checking lock on
> 533fb79ba23b27e9e0715b51daeb30c1
> 2018-07-29 01:45:33,003
> WARN [PEWorker-4] procedure2.ProcedureExecutor: Worker terminating
> UNNATURALLY null
> java.lang.IllegalArgumentException: pid=1820,
> state=WAITING:MOVE_REGION_ASSIGN; MoveRegionProcedure
> hri=533fb79ba23b27e9e0715b51daeb30c1,
> source=ve0538.halxg.cloudera.com,16020,1532847421672,
> destination=ve0540.halxg.cloudera.com,16020,1532853151031
> at
> org.apache.hbase.thirdparty.com.google.common.base.Preconditions.checkArgument(Preconditions.java:134)
>
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.execProcedure(ProcedureExecutor.java:1458)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.executeProcedure(ProcedureExecutor.java:1249)
>
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor.access$900(ProcedureExecutor.java:76)
> at
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor$WorkerThread.run(ProcedureExecutor.java:1763)
> {code}
> It then shows as the below in the UI:
> {code}
> IdParent State Owner TypeStart Time Last Update Errors
> Parameters
> 1820 WAITING stack MoveRegionProcedure
> hri=533fb79ba23b27e9e0715b51daeb30c1,
> source=ve0538.halxg.cloudera.com,16020,1532847421672,
> destination=ve0540.halxg.cloudera.com,16020,1532853151031 Sun Jul 29
> 01:33:37 PDT 2018Sun Jul 29 01:33:38 PDT 2018[ { state => [
> '1', '2' ] }, { regionId => '1532851768240', tableName => { namespace =>
> 'ZGVmYXVsdA==', qualifier => 'SW50ZWdyYXRpb25UZXN0QmlnTGlua2VkTGlzdA==' },
> startKey => 'VttDLvXHdcmzwqNdrNoUFg==', endKey => 'WGFV8k+hFqhcIJGiKZ8L4Q==',
> offline => 'false', split => 'false', replicaId => '0' }, { sourceServer => {
> hostName => 've0538.halxg.cloudera.com', port => '16020
[jira] [Commented] (HBASE-20651) Master, prevents hbck or shell command to reassign the split parent region
[ https://issues.apache.org/jira/browse/HBASE-20651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566170#comment-16566170 ] huaxiang sun commented on HBASE-20651: -- At this moment, it does not seem a regression. I am keeping this open until the root cause is known. > Master, prevents hbck or shell command to reassign the split parent region > -- > > Key: HBASE-20651 > URL: https://issues.apache.org/jira/browse/HBASE-20651 > Project: HBase > Issue Type: Improvement > Components: master >Affects Versions: 1.2.6 >Reporter: huaxiang sun >Assignee: huaxiang sun >Priority: Minor > Fix For: 1.5.0, 1.2.7, 1.3.3, 1.4.6 > > Attachments: HBASE-20651-branch-1-v001.patch, > HBASE-20651-branch-1-v002.patch, HBASE-20651-branch-1-v003.patch > > > We are seeing that hbck brings back split parent region and this causes > region inconsistency. More details will be filled as reproduce is still > ongoing. Might need to do something at hbck or master to prevent this from > happening. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20749) Upgrade our use of checkstyle to 8.6+
[
https://issues.apache.org/jira/browse/HBASE-20749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566160#comment-16566160
]
Hadoop QA commented on HBASE-20749:
---
| (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} @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} 5m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
22s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
40s{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
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
1s{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 4s{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} javadoc {color} | {color:green} 3m
2s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:red}-1{color} | {color:red} unit {color} | {color:red}215m 15s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
4s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}277m 19s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.backup.TestFullRestore |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-20749 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933960/HBASE-20749.master.003.patch
|
| Optional Tests | asflicense checkstyle javac javadoc unit xml
shadedjars hadoopcheck compile |
| uname | Linux e4291d1f4f98 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / 1d0fca370b |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_171 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/13888/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/13888/testReport/ |
| Max. proce
[jira] [Commented] (HBASE-20935) HStore.removeCompactedFiles should log in case it is unable to delete a file
[
https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566143#comment-16566143
]
Hudson commented on HBASE-20935:
Results for branch branch-1.3
[build #410 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.3/410/]:
(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.3/410//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.3/410//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.3/410//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> HStore.removeCompactedFiles should log in case it is unable to delete a file
>
>
> Key: HBASE-20935
> URL: https://issues.apache.org/jira/browse/HBASE-20935
> Project: HBase
> Issue Type: Improvement
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-20935.branch-1.3.patch,
> HBASE-20935.branch-1.3.v2.patch, HBASE-20935.patch, HBASE-20935.v2.patch
>
>
> if (r != null && r.isCompactedAway() && !r.isReferencedInReads())
> If above check fails then there will be some files which are compacted but
> not getting cleaned up. It is good to log which helps in debugging the issue.
> This would let us know why is getting cleaned. either with reference pending
> or compatedaway is not set.
> This will help debug issues like :
> # HBASE-20933
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20794) CreateTable operation does not log its landing at the master nor the initiator at INFO level
[
https://issues.apache.org/jira/browse/HBASE-20794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566124#comment-16566124
]
Hudson commented on HBASE-20794:
Results for branch branch-2
[build #1054 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1054/]:
(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/1054//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/1054//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/1054//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> CreateTable operation does not log its landing at the master nor the
> initiator at INFO level
>
>
> Key: HBASE-20794
> URL: https://issues.apache.org/jira/browse/HBASE-20794
> Project: HBase
> Issue Type: Bug
> Components: logging
>Reporter: stack
>Assignee: Xu Cang
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20794.master.001.patch
>
>
> We don't log at INFO level the arrival on the Master of a create table
> request. Need to log for basic audit purposes the initiator and the pid
> created to run the create table.
> Review other macro ops to make sure they log at INFO level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20989) Minor, miscellaneous logging fixes
[
https://issues.apache.org/jira/browse/HBASE-20989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566125#comment-16566125
]
Hudson commented on HBASE-20989:
Results for branch branch-2
[build #1054 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1054/]:
(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/1054//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/1054//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/1054//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Minor, miscellaneous logging fixes
> --
>
> Key: HBASE-20989
> URL: https://issues.apache.org/jira/browse/HBASE-20989
> Project: HBase
> Issue Type: Task
> Components: logging
>Reporter: stack
>Assignee: stack
>Priority: Trivial
> Fix For: 2.0.2
>
> Attachments: HBASE-20989.branch-2.0.001.patch,
> HBASE-20989.branch-2.0.002.patch
>
>
> Minor logging fixes made this morning while staring at logs.
> In particular, change the AsyncRequestFutureImpl so it puts exception on end
> of the log line rather than in the middle because then we miss the important
> stuff like how long it has been trying...
> Below is new format.
> 2018-07-31 12:46:48,566 WARN [hconnection-0x9a19380-shared-pool12-t646]
> client.AsyncRequestFutureImpl(790): id=5, table=testRowMutation,
> attempt=1/16, on localhost,49798,1533066266628, tracking started Tue Jul 31
> 12:46:48 PDT 2018; not retrying, failed=1 - final failure, failureCount=1
> ops, last
> exception=org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family bogus does not exist in region
> testRowMutation,,1533066407822.252dbbcb173e969f0eed4954e47dacdc. in table
> 'testRowMutation', {NAME => 'testFamily', VERSIONS => '1',
> EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false',
> KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false',
> DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0',
> REPLICATION_SCOPE => '0', BLOOMFILTER => 'NONE', CACHE_INDEX_ON_WRITE =>
> 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false',
> PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE =>
> 'true', BLOCKSIZE => '65536'}
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamily(HRegion.java:7897)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamilies(HRegion.java:4288)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPreparePut(HRegion.java:3391)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3122)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3132)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation$1.visit(HRegion.java:3417)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3015)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPrepare(HRegion.java:3397)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3834)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3768)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:1027)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doAtomicBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2648)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:42014)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> It currently is like this
> ve0528.halxg.cloudera.com_52178:2018-07-31 09:11:08,486 WARN
> [htable-pool3-t35] or
[jira] [Commented] (HBASE-20989) Minor, miscellaneous logging fixes
[
https://issues.apache.org/jira/browse/HBASE-20989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566091#comment-16566091
]
Hudson commented on HBASE-20989:
Results for branch branch-2.1
[build #132 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132/]:
(/) *{color:green}+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/132//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Minor, miscellaneous logging fixes
> --
>
> Key: HBASE-20989
> URL: https://issues.apache.org/jira/browse/HBASE-20989
> Project: HBase
> Issue Type: Task
> Components: logging
>Reporter: stack
>Assignee: stack
>Priority: Trivial
> Fix For: 2.0.2
>
> Attachments: HBASE-20989.branch-2.0.001.patch,
> HBASE-20989.branch-2.0.002.patch
>
>
> Minor logging fixes made this morning while staring at logs.
> In particular, change the AsyncRequestFutureImpl so it puts exception on end
> of the log line rather than in the middle because then we miss the important
> stuff like how long it has been trying...
> Below is new format.
> 2018-07-31 12:46:48,566 WARN [hconnection-0x9a19380-shared-pool12-t646]
> client.AsyncRequestFutureImpl(790): id=5, table=testRowMutation,
> attempt=1/16, on localhost,49798,1533066266628, tracking started Tue Jul 31
> 12:46:48 PDT 2018; not retrying, failed=1 - final failure, failureCount=1
> ops, last
> exception=org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family bogus does not exist in region
> testRowMutation,,1533066407822.252dbbcb173e969f0eed4954e47dacdc. in table
> 'testRowMutation', {NAME => 'testFamily', VERSIONS => '1',
> EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false',
> KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false',
> DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0',
> REPLICATION_SCOPE => '0', BLOOMFILTER => 'NONE', CACHE_INDEX_ON_WRITE =>
> 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false',
> PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE =>
> 'true', BLOCKSIZE => '65536'}
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamily(HRegion.java:7897)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamilies(HRegion.java:4288)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPreparePut(HRegion.java:3391)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3122)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3132)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation$1.visit(HRegion.java:3417)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3015)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPrepare(HRegion.java:3397)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3834)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3768)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:1027)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doAtomicBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2648)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:42014)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> It currently is like this
> ve0528.halxg.cloudera.com_52178:2018-07-31 09:11:08,486 WARN
> [htable-po
[jira] [Commented] (HBASE-20794) CreateTable operation does not log its landing at the master nor the initiator at INFO level
[
https://issues.apache.org/jira/browse/HBASE-20794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566090#comment-16566090
]
Hudson commented on HBASE-20794:
Results for branch branch-2.1
[build #132 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132/]:
(/) *{color:green}+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/132//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/132//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> CreateTable operation does not log its landing at the master nor the
> initiator at INFO level
>
>
> Key: HBASE-20794
> URL: https://issues.apache.org/jira/browse/HBASE-20794
> Project: HBase
> Issue Type: Bug
> Components: logging
>Reporter: stack
>Assignee: Xu Cang
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20794.master.001.patch
>
>
> We don't log at INFO level the arrival on the Master of a create table
> request. Need to log for basic audit purposes the initiator and the pid
> created to run the create table.
> Review other macro ops to make sure they log at INFO level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20657) Retrying RPC call for ModifyTableProcedure may get stuck
[
https://issues.apache.org/jira/browse/HBASE-20657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566057#comment-16566057
]
Duo Zhang commented on HBASE-20657:
---
For now the holdLock method can not be true for most table related procedures,
as we need to hold shared table lock when assign/unassign a region. If you hold
the exclusive for a table, then when a server crash happens, the regions can
not be online until you finish the procedure... This will hurt the
availability...
> Retrying RPC call for ModifyTableProcedure may get stuck
>
>
> Key: HBASE-20657
> URL: https://issues.apache.org/jira/browse/HBASE-20657
> Project: HBase
> Issue Type: Bug
> Components: Client, proc-v2
>Affects Versions: 2.0.0
>Reporter: Sergey Soldatov
>Assignee: stack
>Priority: Critical
> Fix For: 3.0.0, 2.0.2, 2.1.1
>
> Attachments: HBASE-20657-1-branch-2.patch,
> HBASE-20657-2-branch-2.patch, HBASE-20657-3-branch-2.patch,
> HBASE-20657-4-master.patch, HBASE-20657-testcase-branch2.patch
>
>
> Env: 2 masters, 1 RS.
> Steps to reproduce: Active master is killed while ModifyTableProcedure is
> executed.
> If the table has enough regions it may come that when the secondary master
> get active some of the regions may be closed, so once client retries the call
> to the new active master, a new ModifyTableProcedure is created and get stuck
> during MODIFY_TABLE_REOPEN_ALL_REGIONS state handling. That happens because:
> 1. When we are retrying from client side, we call modifyTableAsync which
> create a procedure with a new nonce key:
> {noformat}
> ModifyTableRequest request =
> RequestConverter.buildModifyTableRequest(
> td.getTableName(), td, ng.getNonceGroup(), ng.newNonce());
> {noformat}
> So on the server side, it's considered as a new procedure and starts
> executing immediately.
> 2. When we are processing MODIFY_TABLE_REOPEN_ALL_REGIONS we create
> MoveRegionProcedure for each region, but it checks whether the region is
> online (and it's not), so it fails immediately, forcing the procedure to
> restart.
> [~an...@apache.org] saw a similar case when two concurrent ModifyTable
> procedures were running and got stuck in the similar way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zach York updated HBASE-20856: -- Resolution: Fixed Status: Resolved (was: Patch Available) > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566047#comment-16566047 ] Zach York commented on HBASE-20856: --- Resolving. Anyone know why I don't see an option to be able to close the PRs? [~busbey] [~stack] [~Apache9] I think [~taklwu] can close them, but from a maintenance perspective, it would be good for a committer to be able to close PRs. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566046#comment-16566046 ] Zach York commented on HBASE-20856: --- Pushed to master, branch-2, branch-2.1, and branch-2.0. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20794) CreateTable operation does not log its landing at the master nor the initiator at INFO level
[
https://issues.apache.org/jira/browse/HBASE-20794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566037#comment-16566037
]
Mike Drob commented on HBASE-20794:
---
Hmm... Should this have used the same pid=XXX style of logging that the rest of
Pv2 state machine does? The text {{procId is: XXX}} will be different from the
process operators are learning about for debugging HBase 2
> CreateTable operation does not log its landing at the master nor the
> initiator at INFO level
>
>
> Key: HBASE-20794
> URL: https://issues.apache.org/jira/browse/HBASE-20794
> Project: HBase
> Issue Type: Bug
> Components: logging
>Reporter: stack
>Assignee: Xu Cang
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20794.master.001.patch
>
>
> We don't log at INFO level the arrival on the Master of a create table
> request. Need to log for basic audit purposes the initiator and the pid
> created to run the create table.
> Review other macro ops to make sure they log at INFO level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16566034#comment-16566034 ] Ted Yu commented on HBASE-20894: No additional comment. > 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-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=16566029#comment-16566029 ] Mike Drob commented on HBASE-20894: --- [~tedyu] - any additional comments? > 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-20989) Minor, miscellaneous logging fixes
[
https://issues.apache.org/jira/browse/HBASE-20989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566027#comment-16566027
]
Hudson commented on HBASE-20989:
Results for branch branch-2.0
[build #620 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/620/]:
(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.0/620//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.0/620//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/620//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Minor, miscellaneous logging fixes
> --
>
> Key: HBASE-20989
> URL: https://issues.apache.org/jira/browse/HBASE-20989
> Project: HBase
> Issue Type: Task
> Components: logging
>Reporter: stack
>Assignee: stack
>Priority: Trivial
> Fix For: 2.0.2
>
> Attachments: HBASE-20989.branch-2.0.001.patch,
> HBASE-20989.branch-2.0.002.patch
>
>
> Minor logging fixes made this morning while staring at logs.
> In particular, change the AsyncRequestFutureImpl so it puts exception on end
> of the log line rather than in the middle because then we miss the important
> stuff like how long it has been trying...
> Below is new format.
> 2018-07-31 12:46:48,566 WARN [hconnection-0x9a19380-shared-pool12-t646]
> client.AsyncRequestFutureImpl(790): id=5, table=testRowMutation,
> attempt=1/16, on localhost,49798,1533066266628, tracking started Tue Jul 31
> 12:46:48 PDT 2018; not retrying, failed=1 - final failure, failureCount=1
> ops, last
> exception=org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family bogus does not exist in region
> testRowMutation,,1533066407822.252dbbcb173e969f0eed4954e47dacdc. in table
> 'testRowMutation', {NAME => 'testFamily', VERSIONS => '1',
> EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false',
> KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false',
> DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0',
> REPLICATION_SCOPE => '0', BLOOMFILTER => 'NONE', CACHE_INDEX_ON_WRITE =>
> 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false',
> PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE =>
> 'true', BLOCKSIZE => '65536'}
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamily(HRegion.java:7897)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamilies(HRegion.java:4288)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPreparePut(HRegion.java:3391)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3122)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3132)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation$1.visit(HRegion.java:3417)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3015)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPrepare(HRegion.java:3397)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3834)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3768)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:1027)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doAtomicBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2648)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:42014)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> It currently is like this
> ve0528.halxg.cloudera.com_52178:2018-07-31 09:11:08,486 WARN
> [htable-pool3-t35] org.apache.hadoop.hbase.client.AsyncRequestFutur
[jira] [Commented] (HBASE-20794) CreateTable operation does not log its landing at the master nor the initiator at INFO level
[
https://issues.apache.org/jira/browse/HBASE-20794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566026#comment-16566026
]
Hudson commented on HBASE-20794:
Results for branch branch-2.0
[build #620 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/620/]:
(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.0/620//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.0/620//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/620//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> CreateTable operation does not log its landing at the master nor the
> initiator at INFO level
>
>
> Key: HBASE-20794
> URL: https://issues.apache.org/jira/browse/HBASE-20794
> Project: HBase
> Issue Type: Bug
> Components: logging
>Reporter: stack
>Assignee: Xu Cang
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20794.master.001.patch
>
>
> We don't log at INFO level the arrival on the Master of a create table
> request. Need to log for basic audit purposes the initiator and the pid
> created to run the create table.
> Review other macro ops to make sure they log at INFO level.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16566021#comment-16566021
]
Hadoop QA commented on HBASE-20894:
---
| (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 3 new or modified test
files. {color} |
|| || || || {color:brown} master Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
2s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
56s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m
25s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 33s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {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
58s{color} | {color:green} hbase-server: The patch generated 0 new + 85
unchanged - 11 fixed = 85 total (was 96) {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
2s{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 6s{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 0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
5s{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:green}+1{color} | {color:green} unit {color} | {color:green} 0m
29s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}111m
52s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
42s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}160m 47s{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-20894 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933958/HBASE-20894.master.006.p
[jira] [Updated] (HBASE-19036) Add action in Chaos Monkey to restart Active Namenode
[ https://issues.apache.org/jira/browse/HBASE-19036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated HBASE-19036: - Status: Open (was: Patch Available) > Add action in Chaos Monkey to restart Active Namenode > - > > Key: HBASE-19036 > URL: https://issues.apache.org/jira/browse/HBASE-19036 > Project: HBase > Issue Type: Improvement >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Minor > Attachments: HBASE-19036.branch-1.001.patch, > HBASE-19036.branch-1.001.patch, HBASE-19036.branch-1.002.patch, > HBASE-19036.branch-1.002.patch, HBASE-19036.branch-1.003.patch, > HBASE-19036.branch-1.004.patch, HBASE-19036.master.001.patch, > HBASE-19036.master.002.patch, HBASE-19036.master.003.patch > > > Under hbase-it we have many actions related to DataNode, Zookeeper, HMaster > which gets use with Chaos Monkey and they are useful in testing . Having > action which restart Active Namenode would be useful too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-19036) Add action in Chaos Monkey to restart Active Namenode
[ https://issues.apache.org/jira/browse/HBASE-19036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Monani Mihir updated HBASE-19036: - Status: Patch Available (was: Open) Re-submitting patch for Fresh Run > Add action in Chaos Monkey to restart Active Namenode > - > > Key: HBASE-19036 > URL: https://issues.apache.org/jira/browse/HBASE-19036 > Project: HBase > Issue Type: Improvement >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Minor > Attachments: HBASE-19036.branch-1.001.patch, > HBASE-19036.branch-1.001.patch, HBASE-19036.branch-1.002.patch, > HBASE-19036.branch-1.002.patch, HBASE-19036.branch-1.003.patch, > HBASE-19036.branch-1.004.patch, HBASE-19036.master.001.patch, > HBASE-19036.master.002.patch, HBASE-19036.master.003.patch > > > Under hbase-it we have many actions related to DataNode, Zookeeper, HMaster > which gets use with Chaos Monkey and they are useful in testing . Having > action which restart Active Namenode would be useful too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16566003#comment-16566003 ] Tak Lon (Stephen) Wu commented on HBASE-20856: -- discussed offline with [~zyork], provided the port to branch-2, built and tested (see [PR#88|https://github.com/apache/hbase/pull/88]) and tried cherry-pick on branch-2.0 and branch-2.1. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tak Lon (Stephen) Wu updated HBASE-20856: - Attachment: HBASE-20856.branch-2.002.patch > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.branch-2.002.patch, HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tak Lon (Stephen) Wu updated HBASE-20856: - Attachment: HBASE-20856.branch-2.001.patch > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.branch-2.001.patch, > HBASE-20856.master.001.patch, HBASE-20856.master.002.patch, > HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20897) Port HBASE-20866 "HBase 1.x scan performance degradation compared to 0.98 version" to branch-2 and up
[ https://issues.apache.org/jira/browse/HBASE-20897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20897: -- Fix Version/s: (was: 2.0.2) > Port HBASE-20866 "HBase 1.x scan performance degradation compared to 0.98 > version" to branch-2 and up > - > > Key: HBASE-20897 > URL: https://issues.apache.org/jira/browse/HBASE-20897 > Project: HBase > Issue Type: Sub-task > Components: Performance >Reporter: Andrew Purtell >Assignee: Vikas Vishwakarma >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20981) Rollback stateCount accounting thrown-off when exception out of rollbackState
[
https://issues.apache.org/jira/browse/HBASE-20981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565983#comment-16565983
]
stack commented on HBASE-20981:
---
Excellent. Thank you for working on this [~jackbearden].
FYI, we usually annotate data members or methods we give more visibility to
just so we can better test with @VisibleForTesting. For the next time. Its
kinda useless, just a pallative, but it does give a bit of signal that only
testers should be using methods denoted so.
+1 on patch from me. Nice test. I could commit and fix checkstyle on commit but
lets see if [~allan163] has any input... otherwise I'll commit tomorrow. Thanks.
> Rollback stateCount accounting thrown-off when exception out of rollbackState
> -
>
> Key: HBASE-20981
> URL: https://issues.apache.org/jira/browse/HBASE-20981
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.1
>Reporter: stack
>Assignee: Jack Bearden
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20981.002.patch, HBASE-20981.branch-2.001.patch
>
>
> Found by might [~allan163] over in HBASE-20893. Quoting Allan:
> {code}
> But, there is truly a bug here,
> @Override
> protected void rollback(final TEnvironment env)
> throws IOException, InterruptedException {
> if (isEofState()) stateCount--;
> try {
> updateTimestamp();
> rollbackState(env, getCurrentState());
> stateCount--;
> } finally {
> updateTimestamp();
> }
> }
> We need to decrease the stateCount when rolling back, so we can rollback for
> the previous state correctly. But. since a exception is thrown, the decrease
> for stateCount never happen. So ProcedureExecutor will continue to rollback
> for only one state(the one throw a exception) until the end of the execution
> stack.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20981) Rollback stateCount accounting thrown-off when exception out of rollbackState
[
https://issues.apache.org/jira/browse/HBASE-20981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565963#comment-16565963
]
Hadoop QA commented on HBASE-20981:
---
| (x) *{color:red}-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} 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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} master passed {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:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
13s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
55s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m
15s{color} | {color:red} hbase-procedure: The patch generated 1 new + 11
unchanged - 0 fixed = 12 total (was 11) {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
40s{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 16s{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} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
13s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
43s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 40s{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-20981 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933969/HBASE-20981.002.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 270e775f17e1 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 / d53a976e8d |
| 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/13889/artifact/patchprocess/diff-checkstyle-hbase-procedure.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/13889/testReport/ |
| Max. process+thread count | 280 (vs. ulimit of 1) |
| modules | C: hbase-procedure U: hbase-procedure |
| Console outp
[jira] [Commented] (HBASE-20935) HStore.removeCompactedFiles should log in case it is unable to delete a file
[
https://issues.apache.org/jira/browse/HBASE-20935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565954#comment-16565954
]
Hudson commented on HBASE-20935:
Results for branch branch-1.4
[build #404 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-1.4/404/]:
(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/404//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/404//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/404//JDK8_Nightly_Build_Report_(Hadoop2)/]
(x) {color:red}-1 source release artifact{color}
-- See build output for details.
> HStore.removeCompactedFiles should log in case it is unable to delete a file
>
>
> Key: HBASE-20935
> URL: https://issues.apache.org/jira/browse/HBASE-20935
> Project: HBase
> Issue Type: Improvement
>Reporter: Vishal Khandelwal
>Assignee: Vishal Khandelwal
>Priority: Minor
> Fix For: 3.0.0, 1.5.0, 1.3.3, 2.0.2, 2.2.0, 2.1.1, 1.4.7
>
> Attachments: HBASE-20935.branch-1.3.patch,
> HBASE-20935.branch-1.3.v2.patch, HBASE-20935.patch, HBASE-20935.v2.patch
>
>
> if (r != null && r.isCompactedAway() && !r.isReferencedInReads())
> If above check fails then there will be some files which are compacted but
> not getting cleaned up. It is good to log which helps in debugging the issue.
> This would let us know why is getting cleaned. either with reference pending
> or compatedaway is not set.
> This will help debug issues like :
> # HBASE-20933
--
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=16565909#comment-16565909
]
Hudson commented on HBASE-18477:
Results for branch HBASE-18477
[build #282 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-18477/282/]:
(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/282//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/282//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/282//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/282//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] [Updated] (HBASE-20981) Rollback stateCount accounting thrown-off when exception out of rollbackState
[
https://issues.apache.org/jira/browse/HBASE-20981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Bearden updated HBASE-20981:
-
Attachment: HBASE-20981.002.patch
Status: Patch Available (was: Open)
Patch #2 fixes the state counting on testYieldOnInterrupt()
Please review
> Rollback stateCount accounting thrown-off when exception out of rollbackState
> -
>
> Key: HBASE-20981
> URL: https://issues.apache.org/jira/browse/HBASE-20981
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.1
>Reporter: stack
>Assignee: Jack Bearden
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20981.002.patch, HBASE-20981.branch-2.001.patch
>
>
> Found by might [~allan163] over in HBASE-20893. Quoting Allan:
> {code}
> But, there is truly a bug here,
> @Override
> protected void rollback(final TEnvironment env)
> throws IOException, InterruptedException {
> if (isEofState()) stateCount--;
> try {
> updateTimestamp();
> rollbackState(env, getCurrentState());
> stateCount--;
> } finally {
> updateTimestamp();
> }
> }
> We need to decrease the stateCount when rolling back, so we can rollback for
> the previous state correctly. But. since a exception is thrown, the decrease
> for stateCount never happen. So ProcedureExecutor will continue to rollback
> for only one state(the one throw a exception) until the end of the execution
> stack.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[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=16565897#comment-16565897
]
Hadoop QA commented on HBASE-20894:
---
| (x) *{color:red}-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} 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 3 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
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{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
2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 2m
43s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 1m 44s{color}
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188
total (was 188) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
9s{color} | {color:green} The patch hbase-protocol-shaded passed checkstyle
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
11s{color} | {color:green} hbase-server: The patch generated 0 new + 85
unchanged - 11 fixed = 85 total (was 96) {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}
10m 38s{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 9s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{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}118m
48s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
40s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}171m 38s{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-20894 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933942/HBASE-20894.master.005.p
[jira] [Updated] (HBASE-20981) Rollback stateCount accounting thrown-off when exception out of rollbackState
[
https://issues.apache.org/jira/browse/HBASE-20981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Bearden updated HBASE-20981:
-
Status: Open (was: Patch Available)
> Rollback stateCount accounting thrown-off when exception out of rollbackState
> -
>
> Key: HBASE-20981
> URL: https://issues.apache.org/jira/browse/HBASE-20981
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.1
>Reporter: stack
>Assignee: Jack Bearden
>Priority: Major
> Fix For: 2.0.2
>
> Attachments: HBASE-20981.branch-2.001.patch
>
>
> Found by might [~allan163] over in HBASE-20893. Quoting Allan:
> {code}
> But, there is truly a bug here,
> @Override
> protected void rollback(final TEnvironment env)
> throws IOException, InterruptedException {
> if (isEofState()) stateCount--;
> try {
> updateTimestamp();
> rollbackState(env, getCurrentState());
> stateCount--;
> } finally {
> updateTimestamp();
> }
> }
> We need to decrease the stateCount when rolling back, so we can rollback for
> the previous state correctly. But. since a exception is thrown, the decrease
> for stateCount never happen. So ProcedureExecutor will continue to rollback
> for only one state(the one throw a exception) until the end of the execution
> stack.
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20729) B&R BackupLogCleaner must ignore ProcV2 WAL files
[ https://issues.apache.org/jira/browse/HBASE-20729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-20729: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 3.0.0 Status: Resolved (was: Patch Available) Thanks for the patch, Vlad > B&R BackupLogCleaner must ignore ProcV2 WAL files > - > > Key: HBASE-20729 > URL: https://issues.apache.org/jira/browse/HBASE-20729 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20729-v1.patch, HBASE-20729-v2.patch, > HBASE-20729-v3.patch > > > These are WAL files B&R does need for backup. The issue does not affect B&R > functionality though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20729) B&R BackupLogCleaner must ignore ProcV2 WAL files
[
https://issues.apache.org/jira/browse/HBASE-20729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565836#comment-16565836
]
Hadoop QA commented on HBASE-20729:
---
| (/) *{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:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
19s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
43s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} 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 40s{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} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m
40s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 50m 23s{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-20729 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933953/HBASE-20729-v3.patch |
| Optional Tests | asflicense javac javadoc unit findbugs shadedjars
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 54b3a7fb3c90 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@2/component/dev-support/hbase-personality.sh
|
| git revision | master / e7b56c3fa8 |
| 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/13886/testReport/ |
| Max. process+thread count | 4095 (vs. ulimit of 1) |
| modules | C: hbase-backup U: hbase-backup |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13886/c
[jira] [Updated] (HBASE-20749) Upgrade our use of checkstyle to 8.6+
[ https://issues.apache.org/jira/browse/HBASE-20749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-20749: -- Attachment: HBASE-20749.master.003.patch > Upgrade our use of checkstyle to 8.6+ > - > > Key: HBASE-20749 > URL: https://issues.apache.org/jira/browse/HBASE-20749 > Project: HBase > Issue Type: Improvement > Components: build, community >Reporter: Sean Busbey >Assignee: Mike Drob >Priority: Minor > Attachments: HBASE-20749.master.001.patch, > HBASE-20749.master.002.patch, HBASE-20749.master.003.patch > > > We should upgrade our checkstyle version to 8.6 or later so we can use the > "match violation message to this regex" feature for suppression. That will > allow us to make sure we don't regress on HTrace v3 vs v4 APIs (came up in > HBASE-20332). > We're currently blocked on upgrading to 8.3+ by [checkstyle > #5279|https://github.com/checkstyle/checkstyle/issues/5279], a regression > that flags our use of both the "separate import groups" and "put static > imports over here" configs as an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20550) Document about MasterProcWAL
[ https://issues.apache.org/jira/browse/HBASE-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20550: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to master branch after minor edit. Thanks for the nice contrib [~daisuke.kobayashi] (Do you have an email? It does not show in your JIRA profile. Please edit and add it. Thanks). > Document about MasterProcWAL > > > Key: HBASE-20550 > URL: https://issues.apache.org/jira/browse/HBASE-20550 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Daisuke Kobayashi >Assignee: Daisuke Kobayashi >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20550.master.001.patch, HBASE-20550.patch > > > Lack of contents about MasterProcWAL even it has been present since 1.x > release. I just did a small write-up and appreciate if experts could review > it. > One thing I'm missing is: how to troubleshoot a case once the WAL file gets > increased in size abruptly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20550) Document about MasterProcWAL
[ https://issues.apache.org/jira/browse/HBASE-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20550: -- Fix Version/s: (was: 2.0.2) 3.0.0 > Document about MasterProcWAL > > > Key: HBASE-20550 > URL: https://issues.apache.org/jira/browse/HBASE-20550 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Daisuke Kobayashi >Assignee: Daisuke Kobayashi >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-20550.master.001.patch, HBASE-20550.patch > > > Lack of contents about MasterProcWAL even it has been present since 1.x > release. I just did a small write-up and appreciate if experts could review > it. > One thing I'm missing is: how to troubleshoot a case once the WAL file gets > increased in size abruptly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20894) Move BucketCache from java serialization to protobuf
[ https://issues.apache.org/jira/browse/HBASE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-20894: -- Attachment: HBASE-20894.master.006.patch > 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] [Updated] (HBASE-20550) Document about MasterProcWAL
[ https://issues.apache.org/jira/browse/HBASE-20550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20550: -- Attachment: HBASE-20550.master.001.patch > Document about MasterProcWAL > > > Key: HBASE-20550 > URL: https://issues.apache.org/jira/browse/HBASE-20550 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Daisuke Kobayashi >Assignee: Daisuke Kobayashi >Priority: Minor > Fix For: 2.0.2 > > Attachments: HBASE-20550.master.001.patch, HBASE-20550.patch > > > Lack of contents about MasterProcWAL even it has been present since 1.x > release. I just did a small write-up and appreciate if experts could review > it. > One thing I'm missing is: how to troubleshoot a case once the WAL file gets > increased in size abruptly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20598) Upgrade to JRuby 9.2
[ https://issues.apache.org/jira/browse/HBASE-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565799#comment-16565799 ] Jack Bearden commented on HBASE-20598: -- Ok, sounds good > Upgrade to JRuby 9.2 > > > Key: HBASE-20598 > URL: https://issues.apache.org/jira/browse/HBASE-20598 > Project: HBase > Issue Type: Bug > Components: dependencies, shell >Reporter: Josh Elser >Assignee: Jack Bearden >Priority: Major > Fix For: 3.0.0 > > Attachments: HBASE-20598.001.patch, HBASE-20598.002.patch > > > [~mdrob] pointed out that there's a JRuby 9.2 release. We should see if we > can get ourselves onto that from our current 9.1 release line. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20856) PITA having to set WAL provider in two places
[ https://issues.apache.org/jira/browse/HBASE-20856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565765#comment-16565765 ] Zach York commented on HBASE-20856: --- Sure, I'll commit now. > PITA having to set WAL provider in two places > - > > Key: HBASE-20856 > URL: https://issues.apache.org/jira/browse/HBASE-20856 > Project: HBase > Issue Type: Improvement > Components: Operability, wal >Affects Versions: 3.0.0 >Reporter: stack >Assignee: Tak Lon (Stephen) Wu >Priority: Minor > Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1 > > Attachments: HBASE-20856.master.001.patch, > HBASE-20856.master.002.patch, HBASE-20856.master.003.patch > > > Courtesy of [~elserj], I learn that changing WAL we need to set two places... > both hbase.wal.meta_provider and hbase.wal.provider. Operator should only > have to set it in one place; hbase.wal.meta_provider should pick up general > setting unless hbase.wal.meta_provider is explicitly set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20989) Minor, miscellaneous logging fixes
[
https://issues.apache.org/jira/browse/HBASE-20989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-20989:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to branch-2.0+. Thanks for reviews [~zyork] and [~liuml07].
> Minor, miscellaneous logging fixes
> --
>
> Key: HBASE-20989
> URL: https://issues.apache.org/jira/browse/HBASE-20989
> Project: HBase
> Issue Type: Task
> Components: logging
>Reporter: stack
>Assignee: stack
>Priority: Trivial
> Fix For: 2.0.2
>
> Attachments: HBASE-20989.branch-2.0.001.patch,
> HBASE-20989.branch-2.0.002.patch
>
>
> Minor logging fixes made this morning while staring at logs.
> In particular, change the AsyncRequestFutureImpl so it puts exception on end
> of the log line rather than in the middle because then we miss the important
> stuff like how long it has been trying...
> Below is new format.
> 2018-07-31 12:46:48,566 WARN [hconnection-0x9a19380-shared-pool12-t646]
> client.AsyncRequestFutureImpl(790): id=5, table=testRowMutation,
> attempt=1/16, on localhost,49798,1533066266628, tracking started Tue Jul 31
> 12:46:48 PDT 2018; not retrying, failed=1 - final failure, failureCount=1
> ops, last
> exception=org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family bogus does not exist in region
> testRowMutation,,1533066407822.252dbbcb173e969f0eed4954e47dacdc. in table
> 'testRowMutation', {NAME => 'testFamily', VERSIONS => '1',
> EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false',
> KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false',
> DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0',
> REPLICATION_SCOPE => '0', BLOOMFILTER => 'NONE', CACHE_INDEX_ON_WRITE =>
> 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false',
> PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE =>
> 'true', BLOCKSIZE => '65536'}
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamily(HRegion.java:7897)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamilies(HRegion.java:4288)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPreparePut(HRegion.java:3391)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3122)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3132)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation$1.visit(HRegion.java:3417)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3015)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPrepare(HRegion.java:3397)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3834)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3768)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:1027)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doAtomicBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2648)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:42014)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> It currently is like this
> ve0528.halxg.cloudera.com_52178:2018-07-31 09:11:08,486 WARN
> [htable-pool3-t35] org.apache.hadoop.hbase.client.AsyncRequestFutureImpl:
> id=2, table=IntegrationTestBigLinkedList, attempt=17/16, failed=195ops, last
> exception=org.apache.hadoo
> p.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException:
> IntegrationTestBigLinkedList,\xFE9\x0C\xD4H\xE4[\xCBar!{U\x9C\x9B`,1533052059345.a47fce1dabbcffa6abef3c51b919abd2.
> is not online on ve0532.halxg.clouder
> a.com,16020,1533053378199
> .
> Also add logging of pid to drop table procedure... otherwise it runs silently
> and on big cluster it can be gone for a long time w/o logging as it does hdfs
> ops.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20729) B&R BackupLogCleaner must ignore ProcV2 WAL files
[ https://issues.apache.org/jira/browse/HBASE-20729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Rodionov updated HBASE-20729: -- Attachment: HBASE-20729-v3.patch > B&R BackupLogCleaner must ignore ProcV2 WAL files > - > > Key: HBASE-20729 > URL: https://issues.apache.org/jira/browse/HBASE-20729 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > Attachments: HBASE-20729-v1.patch, HBASE-20729-v2.patch, > HBASE-20729-v3.patch > > > These are WAL files B&R does need for backup. The issue does not affect B&R > functionality though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20729) B&R BackupLogCleaner must ignore ProcV2 WAL files
[ https://issues.apache.org/jira/browse/HBASE-20729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565759#comment-16565759 ] Vladimir Rodionov commented on HBASE-20729: --- Patch v3. > B&R BackupLogCleaner must ignore ProcV2 WAL files > - > > Key: HBASE-20729 > URL: https://issues.apache.org/jira/browse/HBASE-20729 > Project: HBase > Issue Type: Bug >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov >Priority: Major > Attachments: HBASE-20729-v1.patch, HBASE-20729-v2.patch, > HBASE-20729-v3.patch > > > These are WAL files B&R does need for backup. The issue does not affect B&R > functionality though. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20749) Upgrade our use of checkstyle to 8.6+
[
https://issues.apache.org/jira/browse/HBASE-20749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565752#comment-16565752
]
Hudson commented on HBASE-20749:
Results for branch HBASE-20749
[build #10 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20749/10/]:
(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-20749/10//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-20749/10//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-20749/10//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Upgrade our use of checkstyle to 8.6+
> -
>
> Key: HBASE-20749
> URL: https://issues.apache.org/jira/browse/HBASE-20749
> Project: HBase
> Issue Type: Improvement
> Components: build, community
>Reporter: Sean Busbey
>Assignee: Mike Drob
>Priority: Minor
> Attachments: HBASE-20749.master.001.patch,
> HBASE-20749.master.002.patch
>
>
> We should upgrade our checkstyle version to 8.6 or later so we can use the
> "match violation message to this regex" feature for suppression. That will
> allow us to make sure we don't regress on HTrace v3 vs v4 APIs (came up in
> HBASE-20332).
> We're currently blocked on upgrading to 8.3+ by [checkstyle
> #5279|https://github.com/checkstyle/checkstyle/issues/5279], a regression
> that flags our use of both the "separate import groups" and "put static
> imports over here" configs as an error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20671) Merged region brought back to life causing RS to be killed by Master
[
https://issues.apache.org/jira/browse/HBASE-20671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565745#comment-16565745
]
Josh Elser commented on HBASE-20671:
I haven't seen it recently. Not sure if it's "fixed" by something else or not.
Need to sync up with tests runs that have been happening over here..
> Merged region brought back to life causing RS to be killed by Master
>
>
> Key: HBASE-20671
> URL: https://issues.apache.org/jira/browse/HBASE-20671
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.2
>
> Attachments: 0001-Test-for-HBASE-20671.patch,
> hbase-hbase-master-ctr-e138-1518143905142-336066-01-03.hwx.site.log.zip,
> hbase-hbase-regionserver-ctr-e138-1518143905142-336066-01-02.hwx.site.log.zip,
> workaround.txt
>
>
> Another bug coming out of a master restart and replay of the pv2 logs.
> The master merged two regions into one successfully, was restarted, but then
> ended up assigning the children region back out to the cluster. There is a
> log message which appears to indicate that RegionStates acknowledges that it
> doesn't know what this region is as it's replaying the pv2 WAL; however, it
> incorrectly assumes that the region is just OFFLINE and needs to be assigned.
> {noformat}
> 2018-05-30 04:26:00,055 INFO
> [RpcServer.default.FPBQ.Fifo.handler=29,queue=2,port=2] master.HMaster:
> Client=hrt_qa//172.27.85.11 Merge regions a7dd6606dcacc9daf085fc9fa2aecc0c
> and 4017a3c778551d4d258c785d455f9c0b
> 2018-05-30 04:28:27,525 DEBUG
> [master/ctr-e138-1518143905142-336066-01-03:2]
> procedure2.ProcedureExecutor: Completed pid=4368, state=SUCCESS;
> MergeTableRegionsProcedure table=tabletwo_merge,
> regions=[a7dd6606dcacc9daf085fc9fa2aecc0c, 4017a3c778551d4d258c785d455f9c0b],
> forcibly=false
> {noformat}
> {noformat}
> 2018-05-30 04:29:20,263 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.AssignmentManager: a7dd6606dcacc9daf085fc9fa2aecc0c
> regionState=null; presuming OFFLINE
> 2018-05-30 04:29:20,263 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.RegionStates: Added to offline, CURRENTLY NEVER CLEARED!!!
> rit=OFFLINE, location=null, table=tabletwo_merge,
> region=a7dd6606dcacc9daf085fc9fa2aecc0c
> 2018-05-30 04:29:20,266 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.AssignmentManager: 4017a3c778551d4d258c785d455f9c0b
> regionState=null; presuming OFFLINE
> 2018-05-30 04:29:20,266 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.RegionStates: Added to offline, CURRENTLY NEVER CLEARED!!!
> rit=OFFLINE, location=null, table=tabletwo_merge,
> region=4017a3c778551d4d258c785d455f9c0b
> {noformat}
> Eventually, the RS reports in its online regions, and the master tells it to
> kill itself:
> {noformat}
> 2018-05-30 04:29:24,272 WARN
> [RpcServer.default.FPBQ.Fifo.handler=26,queue=2,port=2]
> assignment.AssignmentManager: Killing
> ctr-e138-1518143905142-336066-01-02.hwx.site,16020,1527654546619: Not
> online: tabletwo_merge,,1527652130538.a7dd6606dcacc9daf085fc9fa2aecc0c.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20989) Minor, miscellaneous logging fixes
[
https://issues.apache.org/jira/browse/HBASE-20989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565742#comment-16565742
]
Zach York commented on HBASE-20989:
---
+1
> Minor, miscellaneous logging fixes
> --
>
> Key: HBASE-20989
> URL: https://issues.apache.org/jira/browse/HBASE-20989
> Project: HBase
> Issue Type: Task
> Components: logging
>Reporter: stack
>Assignee: stack
>Priority: Trivial
> Fix For: 2.0.2
>
> Attachments: HBASE-20989.branch-2.0.001.patch,
> HBASE-20989.branch-2.0.002.patch
>
>
> Minor logging fixes made this morning while staring at logs.
> In particular, change the AsyncRequestFutureImpl so it puts exception on end
> of the log line rather than in the middle because then we miss the important
> stuff like how long it has been trying...
> Below is new format.
> 2018-07-31 12:46:48,566 WARN [hconnection-0x9a19380-shared-pool12-t646]
> client.AsyncRequestFutureImpl(790): id=5, table=testRowMutation,
> attempt=1/16, on localhost,49798,1533066266628, tracking started Tue Jul 31
> 12:46:48 PDT 2018; not retrying, failed=1 - final failure, failureCount=1
> ops, last
> exception=org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException:
> org.apache.hadoop.hbase.regionserver.NoSuchColumnFamilyException: Column
> family bogus does not exist in region
> testRowMutation,,1533066407822.252dbbcb173e969f0eed4954e47dacdc. in table
> 'testRowMutation', {NAME => 'testFamily', VERSIONS => '1',
> EVICT_BLOCKS_ON_CLOSE => 'false', NEW_VERSION_BEHAVIOR => 'false',
> KEEP_DELETED_CELLS => 'FALSE', CACHE_DATA_ON_WRITE => 'false',
> DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', MIN_VERSIONS => '0',
> REPLICATION_SCOPE => '0', BLOOMFILTER => 'NONE', CACHE_INDEX_ON_WRITE =>
> 'false', IN_MEMORY => 'false', CACHE_BLOOMS_ON_WRITE => 'false',
> PREFETCH_BLOCKS_ON_OPEN => 'false', COMPRESSION => 'NONE', BLOCKCACHE =>
> 'true', BLOCKSIZE => '65536'}
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamily(HRegion.java:7897)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.checkFamilies(HRegion.java:4288)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPreparePut(HRegion.java:3391)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3122)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.checkAndPrepareMutation(HRegion.java:3132)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation$1.visit(HRegion.java:3417)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$BatchOperation.visitBatchOperations(HRegion.java:3015)
> at
> org.apache.hadoop.hbase.regionserver.HRegion$MutationBatchOperation.checkAndPrepare(HRegion.java:3397)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3834)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:3768)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:1027)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doAtomicBatchOp(RSRpcServices.java:952)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2648)
> at
> org.apache.hadoop.hbase.shaded.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:42014)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:409)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:130)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:324)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:304)
> It currently is like this
> ve0528.halxg.cloudera.com_52178:2018-07-31 09:11:08,486 WARN
> [htable-pool3-t35] org.apache.hadoop.hbase.client.AsyncRequestFutureImpl:
> id=2, table=IntegrationTestBigLinkedList, attempt=17/16, failed=195ops, last
> exception=org.apache.hadoo
> p.hbase.NotServingRegionException:
> org.apache.hadoop.hbase.NotServingRegionException:
> IntegrationTestBigLinkedList,\xFE9\x0C\xD4H\xE4[\xCBar!{U\x9C\x9B`,1533052059345.a47fce1dabbcffa6abef3c51b919abd2.
> is not online on ve0532.halxg.clouder
> a.com,16020,1533053378199
> .
> Also add logging of pid to drop table procedure... otherwise it runs silently
> and on big cluster it can be gone for a long time w/o logging as it does hdfs
> ops.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20794) CreateTable operation does not log its landing at the master nor the initiator at INFO level
[ https://issues.apache.org/jira/browse/HBASE-20794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20794: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Pushed to branch-2.0+ Thank you for the patch [~xucang]. > CreateTable operation does not log its landing at the master nor the > initiator at INFO level > > > Key: HBASE-20794 > URL: https://issues.apache.org/jira/browse/HBASE-20794 > Project: HBase > Issue Type: Bug > Components: logging >Reporter: stack >Assignee: Xu Cang >Priority: Major > Fix For: 2.0.2 > > Attachments: HBASE-20794.master.001.patch > > > We don't log at INFO level the arrival on the Master of a create table > request. Need to log for basic audit purposes the initiator and the pid > created to run the create table. > Review other macro ops to make sure they log at INFO level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20796) STUCK RIT though region successfully assigned (hung RPC)
[
https://issues.apache.org/jira/browse/HBASE-20796?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565727#comment-16565727
]
stack commented on HBASE-20796:
---
Moved this out of 2.0.2. Needs more study. Has a workaround.
> STUCK RIT though region successfully assigned (hung RPC)
>
>
> Key: HBASE-20796
> URL: https://issues.apache.org/jira/browse/HBASE-20796
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-Test.patch, HBASE-20796.branch-2.0.001.patch
>
>
> This is a good one. We keep logging messages like this:
> {code}
> 2018-06-26 12:32:24,859 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OPENING,
> location=vd0410.X.Y.com,22101,1529611445046,
> table=IntegrationTestBigLinkedList_20180525080406,
> region=e10b35d49528e2453a04c7038e3393d7
> {code}
> ...though the region is successfully assigned.
> Story:
> * Dispatch an assign 2018-06-26 12:31:27,390 INFO
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Dispatch
> pid=370829, ppid=370391, state=RUNNABLE:REGION_TRANSITION_DISPATCH;
> AssignProcedure table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046
> * It gets stuck 2018-06-26 12:32:29,860 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OPENING, location=vd0410.X.Y.Z,22101,1529611445046,
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2 (Because the server was killed)
> * We stay STUCK for a while.
> * The Master notices the server as crashed and starts a SCP.
> * SCP kills ongoing assign: 2018-06-26 12:32:54,809 INFO
> org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure: pid=371105
> found RIT pid=370829, ppid=370391, state=RUNNABLE:REGION_TRANSITION_DISPATCH;
> AssignProcedure table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046
> * The kill brings on a retry ... 2018-06-26 12:32:54,810 WARN
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Remote
> call failed pid=370829, ppid=370391,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046; exception=ServerCrashProcedure
> pid=371105, server=vd0410.X.Y.Z,22101,1529611445046
> * Which eventually succeeds. Successfully deployed to new server
> 2018-06-26 12:32:55,429 INFO
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: Finished pid=370829,
> ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2 in 1mins, 35.379sec
> * But then, it looks like the RPC was ongoing and it broke in following way
> 2018-06-26 12:33:06,378 WARN
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Remote
> call failed pid=370829, ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPEN,
> location=vc0614.halxg.cloudera.com,22101,1529611443424; exception=Call to
> vd0410.X.Y.Z/10.10.10.10:22101 failed on local exception:
> org.apache.hbase.thirdparty.io.netty.channel.unix.Errors$NativeIoException:
> syscall:read(..) failed: Connection reset by peer (Notice how state for
> region is OPEN and 'SUCCESS').
> * Then says 2018-06-26 12:33:06,380 INFO
> org.apache.hadoop.hbase.master.assignment.AssignProcedure: Retry=1 of max=10;
> pid=370829, ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPEN,
> location=vc0614.X.Y.Z,22101,1529611443424
> * And finally... 2018-06-26 12:34:10,727 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OFFLINE, location=null,
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2
> Restart of Master got rid of the STUCK complaints.
> This is interesting because the stuck rpc and the successful reassign are all
> riding on the same pid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20796) STUCK RIT though region successfully assigned (hung RPC)
[
https://issues.apache.org/jira/browse/HBASE-20796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-20796:
--
Fix Version/s: (was: 2.1.1)
(was: 2.0.2)
> STUCK RIT though region successfully assigned (hung RPC)
>
>
> Key: HBASE-20796
> URL: https://issues.apache.org/jira/browse/HBASE-20796
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Reporter: stack
>Assignee: stack
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: 0001-Test.patch, HBASE-20796.branch-2.0.001.patch
>
>
> This is a good one. We keep logging messages like this:
> {code}
> 2018-06-26 12:32:24,859 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OPENING,
> location=vd0410.X.Y.com,22101,1529611445046,
> table=IntegrationTestBigLinkedList_20180525080406,
> region=e10b35d49528e2453a04c7038e3393d7
> {code}
> ...though the region is successfully assigned.
> Story:
> * Dispatch an assign 2018-06-26 12:31:27,390 INFO
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Dispatch
> pid=370829, ppid=370391, state=RUNNABLE:REGION_TRANSITION_DISPATCH;
> AssignProcedure table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046
> * It gets stuck 2018-06-26 12:32:29,860 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OPENING, location=vd0410.X.Y.Z,22101,1529611445046,
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2 (Because the server was killed)
> * We stay STUCK for a while.
> * The Master notices the server as crashed and starts a SCP.
> * SCP kills ongoing assign: 2018-06-26 12:32:54,809 INFO
> org.apache.hadoop.hbase.master.procedure.ServerCrashProcedure: pid=371105
> found RIT pid=370829, ppid=370391, state=RUNNABLE:REGION_TRANSITION_DISPATCH;
> AssignProcedure table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046
> * The kill brings on a retry ... 2018-06-26 12:32:54,810 WARN
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Remote
> call failed pid=370829, ppid=370391,
> state=RUNNABLE:REGION_TRANSITION_DISPATCH; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPENING,
> location=vd0410.X.Y.Z,22101,1529611445046; exception=ServerCrashProcedure
> pid=371105, server=vd0410.X.Y.Z,22101,1529611445046
> * Which eventually succeeds. Successfully deployed to new server
> 2018-06-26 12:32:55,429 INFO
> org.apache.hadoop.hbase.procedure2.ProcedureExecutor: Finished pid=370829,
> ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2 in 1mins, 35.379sec
> * But then, it looks like the RPC was ongoing and it broke in following way
> 2018-06-26 12:33:06,378 WARN
> org.apache.hadoop.hbase.master.assignment.RegionTransitionProcedure: Remote
> call failed pid=370829, ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPEN,
> location=vc0614.halxg.cloudera.com,22101,1529611443424; exception=Call to
> vd0410.X.Y.Z/10.10.10.10:22101 failed on local exception:
> org.apache.hbase.thirdparty.io.netty.channel.unix.Errors$NativeIoException:
> syscall:read(..) failed: Connection reset by peer (Notice how state for
> region is OPEN and 'SUCCESS').
> * Then says 2018-06-26 12:33:06,380 INFO
> org.apache.hadoop.hbase.master.assignment.AssignProcedure: Retry=1 of max=10;
> pid=370829, ppid=370391, state=SUCCESS; AssignProcedure
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2; rit=OPEN,
> location=vc0614.X.Y.Z,22101,1529611443424
> * And finally... 2018-06-26 12:34:10,727 WARN
> org.apache.hadoop.hbase.master.assignment.AssignmentManager: STUCK
> Region-In-Transition rit=OFFLINE, location=null,
> table=IntegrationTestBigLinkedList_20180612114844,
> region=f69ccf7d9178ce166b515e0e2ef019d2
> Restart of Master got rid of the STUCK complaints.
> This is interesting because the stuck rpc and the successful reassign are all
> riding on the same pid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20682) MoveProcedure can be subtask of ModifyTableProcedure/ReopenTableRegionsProcedure; ensure all kosher.
[ https://issues.apache.org/jira/browse/HBASE-20682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20682: -- Fix Version/s: (was: 2.0.2) 2.2.0 > MoveProcedure can be subtask of > ModifyTableProcedure/ReopenTableRegionsProcedure; ensure all kosher. > > > Key: HBASE-20682 > URL: https://issues.apache.org/jira/browse/HBASE-20682 > Project: HBase > Issue Type: Sub-task > Components: amv2 >Reporter: stack >Assignee: stack >Priority: Critical > Fix For: 2.2.0 > > > MoveProcedure is used in at least two places as a means of 'reopening' a > region after a config has changed. This issue is about review of MP so this > usage is first-class (and that MP is good procedure citizen running as a > subprocedure. In question is what should happen if the source server or the > target servers are offline when we go to run. As of the parent issue, we'll > skip to the end. Should we instead go ahead with the move (internally, if we > are asked to assign to an offline server, we'll pick another -- do same for > unassign? Would help in this reopen use case). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20671) Merged region brought back to life causing RS to be killed by Master
[
https://issues.apache.org/jira/browse/HBASE-20671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565723#comment-16565723
]
stack commented on HBASE-20671:
---
We still critical on this one given we committed workaround in sub-issue? I
don't see this in my test runs but I don't have merges in the mix. I should add
them?
> Merged region brought back to life causing RS to be killed by Master
>
>
> Key: HBASE-20671
> URL: https://issues.apache.org/jira/browse/HBASE-20671
> Project: HBase
> Issue Type: Bug
> Components: amv2
>Affects Versions: 2.0.0
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 2.0.2
>
> Attachments: 0001-Test-for-HBASE-20671.patch,
> hbase-hbase-master-ctr-e138-1518143905142-336066-01-03.hwx.site.log.zip,
> hbase-hbase-regionserver-ctr-e138-1518143905142-336066-01-02.hwx.site.log.zip,
> workaround.txt
>
>
> Another bug coming out of a master restart and replay of the pv2 logs.
> The master merged two regions into one successfully, was restarted, but then
> ended up assigning the children region back out to the cluster. There is a
> log message which appears to indicate that RegionStates acknowledges that it
> doesn't know what this region is as it's replaying the pv2 WAL; however, it
> incorrectly assumes that the region is just OFFLINE and needs to be assigned.
> {noformat}
> 2018-05-30 04:26:00,055 INFO
> [RpcServer.default.FPBQ.Fifo.handler=29,queue=2,port=2] master.HMaster:
> Client=hrt_qa//172.27.85.11 Merge regions a7dd6606dcacc9daf085fc9fa2aecc0c
> and 4017a3c778551d4d258c785d455f9c0b
> 2018-05-30 04:28:27,525 DEBUG
> [master/ctr-e138-1518143905142-336066-01-03:2]
> procedure2.ProcedureExecutor: Completed pid=4368, state=SUCCESS;
> MergeTableRegionsProcedure table=tabletwo_merge,
> regions=[a7dd6606dcacc9daf085fc9fa2aecc0c, 4017a3c778551d4d258c785d455f9c0b],
> forcibly=false
> {noformat}
> {noformat}
> 2018-05-30 04:29:20,263 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.AssignmentManager: a7dd6606dcacc9daf085fc9fa2aecc0c
> regionState=null; presuming OFFLINE
> 2018-05-30 04:29:20,263 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.RegionStates: Added to offline, CURRENTLY NEVER CLEARED!!!
> rit=OFFLINE, location=null, table=tabletwo_merge,
> region=a7dd6606dcacc9daf085fc9fa2aecc0c
> 2018-05-30 04:29:20,266 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.AssignmentManager: 4017a3c778551d4d258c785d455f9c0b
> regionState=null; presuming OFFLINE
> 2018-05-30 04:29:20,266 INFO
> [master/ctr-e138-1518143905142-336066-01-03:2]
> assignment.RegionStates: Added to offline, CURRENTLY NEVER CLEARED!!!
> rit=OFFLINE, location=null, table=tabletwo_merge,
> region=4017a3c778551d4d258c785d455f9c0b
> {noformat}
> Eventually, the RS reports in its online regions, and the master tells it to
> kill itself:
> {noformat}
> 2018-05-30 04:29:24,272 WARN
> [RpcServer.default.FPBQ.Fifo.handler=26,queue=2,port=2]
> assignment.AssignmentManager: Killing
> ctr-e138-1518143905142-336066-01-02.hwx.site,16020,1527654546619: Not
> online: tabletwo_merge,,1527652130538.a7dd6606dcacc9daf085fc9fa2aecc0c.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20657) Retrying RPC call for ModifyTableProcedure may get stuck
[
https://issues.apache.org/jira/browse/HBASE-20657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565716#comment-16565716
]
stack commented on HBASE-20657:
---
Pardon [~sergey.soldatov]. I've been neglectful. I was trying to put off
bringing back big patches to branch-2.0 but I think it unavoidable now, its
only way to shutdown issues like that you've turned up here. I'm trying to be
careful testing each first. I'll be back here to try your provided test after
they've gone in. Thanks.
> Retrying RPC call for ModifyTableProcedure may get stuck
>
>
> Key: HBASE-20657
> URL: https://issues.apache.org/jira/browse/HBASE-20657
> Project: HBase
> Issue Type: Bug
> Components: Client, proc-v2
>Affects Versions: 2.0.0
>Reporter: Sergey Soldatov
>Assignee: stack
>Priority: Critical
> Fix For: 3.0.0, 2.0.2, 2.1.1
>
> Attachments: HBASE-20657-1-branch-2.patch,
> HBASE-20657-2-branch-2.patch, HBASE-20657-3-branch-2.patch,
> HBASE-20657-4-master.patch, HBASE-20657-testcase-branch2.patch
>
>
> Env: 2 masters, 1 RS.
> Steps to reproduce: Active master is killed while ModifyTableProcedure is
> executed.
> If the table has enough regions it may come that when the secondary master
> get active some of the regions may be closed, so once client retries the call
> to the new active master, a new ModifyTableProcedure is created and get stuck
> during MODIFY_TABLE_REOPEN_ALL_REGIONS state handling. That happens because:
> 1. When we are retrying from client side, we call modifyTableAsync which
> create a procedure with a new nonce key:
> {noformat}
> ModifyTableRequest request =
> RequestConverter.buildModifyTableRequest(
> td.getTableName(), td, ng.getNonceGroup(), ng.newNonce());
> {noformat}
> So on the server side, it's considered as a new procedure and starts
> executing immediately.
> 2. When we are processing MODIFY_TABLE_REOPEN_ALL_REGIONS we create
> MoveRegionProcedure for each region, but it checks whether the region is
> online (and it's not), so it fails immediately, forcing the procedure to
> restart.
> [~an...@apache.org] saw a similar case when two concurrent ModifyTable
> procedures were running and got stuck in the similar way.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20713) Revisit why to removeFromRunQueue in MasterProcedureExecutor's doPoll method
[
https://issues.apache.org/jira/browse/HBASE-20713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-20713:
--
Fix Version/s: 2.0.2
> Revisit why to removeFromRunQueue in MasterProcedureExecutor's doPoll method
> -
>
> Key: HBASE-20713
> URL: https://issues.apache.org/jira/browse/HBASE-20713
> Project: HBase
> Issue Type: Bug
>Reporter: Guanghao Zhang
>Priority: Major
> Fix For: 2.0.2
>
>
> https://github.com/apache/hbase/blob/master/hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/MasterProcedureScheduler.java#L210
> {code:java}
> if (rq.isEmpty() || xlockReq) {
> removeFromRunQueue(fairq, rq);
> } else if (rq.getLockStatus().hasParentLock(pollResult)) {
> // if the rq is in the fairq because of runnable child
> // check if the next procedure is still a child.
> // if not, remove the rq from the fairq and go back to the xlock state
> Procedure nextProc = rq.peek();
> if (nextProc != null && !Procedure.haveSameParent(nextProc,
> pollResult)) {
> removeFromRunQueue(fairq, rq);
> }
> }
> {code}
> Here is the comment of why to remove from run queue. If I am not wrong,
> here's assumption is the parent procedure should require exclusive lock. So
> if the nextProc is a child but has different parent with current procedure,
> we can remove it from run queue.
> But there maybe three type procedure. Procedure A's child is Procedure B.
> Procedure's child is Procedure C. And only Procedure A need exclusive lock
> and Procedure B,C don't require exclusive lock. The
> condition(!Procedure.haveSameParent(nextProc, pollResult)) is not right for
> this case?
> FYI [~stack]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20512) document change to running tests on secure clusters
[ https://issues.apache.org/jira/browse/HBASE-20512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565697#comment-16565697 ] stack commented on HBASE-20512: --- You good w/ this Mr. [~busbey]? > document change to running tests on secure clusters > --- > > Key: HBASE-20512 > URL: https://issues.apache.org/jira/browse/HBASE-20512 > Project: HBase > Issue Type: Task > Components: documentation, integration tests, Usability >Affects Versions: 1.3.0, 2.0.0 >Reporter: Sean Busbey >Assignee: stack >Priority: Critical > Fix For: 3.0.0, 2.0.2 > > Attachments: HBASE-20512.master.001.patch > > > We should document the change to authentication handling in HBASE-16231 in > the upgrade section of the reference guide. > It's surprising to folks that have existing automated testing that's been > working on our prior stable release lines. We should give a warning to those > updating. The release note is probably suitable for a first pass. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16565691#comment-16565691 ] stack commented on HBASE-20894: --- bq. but don't think dropping the leading "is" is correct. It is incorrect. "hasIs..." is 'wrong'. It is a double-verb, duplicated prefix AND they disagree in tense. I think you should change it, but its a 'nit'. bq. Or maybe don't even need to log the filename in this case? No harm logging filename; better than an IOE w/o specifics. If we skip the file, thats fine. Otherwise, +1. > 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 > > > 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-20992) MTTR, Chaos, and ITBLL
[ https://issues.apache.org/jira/browse/HBASE-20992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565682#comment-16565682 ] stack commented on HBASE-20992: --- For now upped hbase.client.retries.number from its default of 15 to 25. Would be better if all recovered inside two minutes. > MTTR, Chaos, and ITBLL > -- > > Key: HBASE-20992 > URL: https://issues.apache.org/jira/browse/HBASE-20992 > Project: HBase > Issue Type: Sub-task > Components: integration tests, MTTR >Reporter: stack >Priority: Major > > I've been having trouble getting a sustained, large ITBLL run to complete > over the last few days. I'm seeing a bunch of the below: > * A region splits or is moved > * Chaos kills the Master in the middle of the Split or Move Procedure after > a Region has been offlined > * Master takes a while to come back whether because it is not started until > a couple of minutes have passed and then there is some recovery to be done. > So a region can be offline for minutes. Default we retry up to 16 times which > ends up at about 2.5 minutes before we give up. > So, I can up the retries when running larger tests but also, the region > should come back online faster. > Let me hang ITBLL fixes/notes off here. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[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=16565677#comment-16565677 ] Mike Drob commented on HBASE-20894: --- bq. required bool isPrimaryReplicaBlock = 4; is a bad name for a data member...Should it be primary_replica_block in pb proc format? As is, it is the name of a method that queries about primaryReplicaBlock (Does PB generate methods that look like isIsPrimaryReplicaBlock?) It generates getIsPrimaryReplicaBlock and hasIsPrimaryReplicaBlock. I can rename to underscores for protobuf style, but don't think dropping the leading "is" is correct. bq. Format of required int32 deserialiserIndex = 4; could change too to deserializer_index? Will do. bq. Should we tell operator remove the old file? Do you know if this IOE kills cache startup or we report and just continue skipping rehydration of persisted cache? The IO skips the file. When we're done with the file (success or failure) we will delete it -- this was the old behavior too. Seems kind of dangerous or surprising maybe? Or maybe don't even need to log the filename in this case? > 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 > > > 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-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=16565652#comment-16565652
]
stack commented on HBASE-20894:
---
nit: 49 required bool isPrimaryReplicaBlock = 4; is a bad name for a data
member...Should it be primary_replica_block in pb proc format? As is, it is
the name of a method that queries about primaryReplicaBlock (Does PB generate
methods that look like isIsPrimaryReplicaBlock?). Format of required int32
deserialiserIndex = 4; could change too to deserializer_index?
On
{code}
1119throw new IOException("Persistence file does not start
with protobuf magic number. " +
1120persistencePath);
{code}
Should we tell operator remove the old file? Do you know if this IOE kills
cache startup or we report and just continue skipping rehydration of persisted
cache?
On above, perhaps add to the IOE message to remove the file?
Otherwise +1. Looks great. Nice cleanup.
> 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
>
>
> 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-20893) Data loss if splitting region while ServerCrashProcedure executing
[
https://issues.apache.org/jira/browse/HBASE-20893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565649#comment-16565649
]
Hudson commented on HBASE-20893:
Results for branch branch-2.1
[build #131 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/131/]:
(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/131//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/131//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/131//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Data loss if splitting region while ServerCrashProcedure executing
> --
>
> Key: HBASE-20893
> URL: https://issues.apache.org/jira/browse/HBASE-20893
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 3.0.0, 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20893-branch-2.0.addendum.patch,
> HBASE-20893.branch-2.0.001.patch, HBASE-20893.branch-2.0.002.patch,
> HBASE-20893.branch-2.0.003.patch, HBASE-20893.branch-2.0.004.patch,
> HBASE-20893.branch-2.0.005.patch
>
>
> Similar case as HBASE-20878.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (HBASE-20894) Move BucketCache from java serialization to protobuf
[ https://issues.apache.org/jira/browse/HBASE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-20894: -- Attachment: HBASE-20894.master.005.patch > 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 > > > 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-20598) Upgrade to JRuby 9.2
[
https://issues.apache.org/jira/browse/HBASE-20598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565633#comment-16565633
]
Josh Elser commented on HBASE-20598:
{quote}Please wait until 9.2.1
{quote}
Yeah, doesn't seem urgent enough to push on this since they should fix things
upstream "soon" :)
> Upgrade to JRuby 9.2
>
>
> Key: HBASE-20598
> URL: https://issues.apache.org/jira/browse/HBASE-20598
> Project: HBase
> Issue Type: Bug
> Components: dependencies, shell
>Reporter: Josh Elser
>Assignee: Jack Bearden
>Priority: Major
> Fix For: 3.0.0
>
> Attachments: HBASE-20598.001.patch, HBASE-20598.002.patch
>
>
> [~mdrob] pointed out that there's a JRuby 9.2 release. We should see if we
> can get ourselves onto that from our current 9.1 release line.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20893) Data loss if splitting region while ServerCrashProcedure executing
[
https://issues.apache.org/jira/browse/HBASE-20893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565610#comment-16565610
]
Hudson commented on HBASE-20893:
Results for branch branch-2
[build #1053 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1053/]:
(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/1053//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/1053//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/1053//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
(/) {color:green}+1 client integration test{color}
> Data loss if splitting region while ServerCrashProcedure executing
> --
>
> Key: HBASE-20893
> URL: https://issues.apache.org/jira/browse/HBASE-20893
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 3.0.0, 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20893-branch-2.0.addendum.patch,
> HBASE-20893.branch-2.0.001.patch, HBASE-20893.branch-2.0.002.patch,
> HBASE-20893.branch-2.0.003.patch, HBASE-20893.branch-2.0.004.patch,
> HBASE-20893.branch-2.0.005.patch
>
>
> Similar case as HBASE-20878.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-20893) Data loss if splitting region while ServerCrashProcedure executing
[
https://issues.apache.org/jira/browse/HBASE-20893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565608#comment-16565608
]
Hudson commented on HBASE-20893:
Results for branch branch-2.0
[build #619 on
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/619/]:
(/) *{color:green}+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.0/619//General_Nightly_Build_Report/]
(/) {color:green}+1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/619//JDK8_Nightly_Build_Report_(Hadoop2)/]
(/) {color:green}+1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3)
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.0/619//JDK8_Nightly_Build_Report_(Hadoop3)/]
(/) {color:green}+1 source release artifact{color}
-- See build output for details.
> Data loss if splitting region while ServerCrashProcedure executing
> --
>
> Key: HBASE-20893
> URL: https://issues.apache.org/jira/browse/HBASE-20893
> Project: HBase
> Issue Type: Sub-task
>Affects Versions: 3.0.0, 2.1.0, 2.0.1
>Reporter: Allan Yang
>Assignee: Allan Yang
>Priority: Major
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20893-branch-2.0.addendum.patch,
> HBASE-20893.branch-2.0.001.patch, HBASE-20893.branch-2.0.002.patch,
> HBASE-20893.branch-2.0.003.patch, HBASE-20893.branch-2.0.004.patch,
> HBASE-20893.branch-2.0.005.patch
>
>
> Similar case as HBASE-20878.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (HBASE-19036) Add action in Chaos Monkey to restart Active Namenode
[ https://issues.apache.org/jira/browse/HBASE-19036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565541#comment-16565541 ] Mike Drob commented on HBASE-19036: --- I tried a few things locally and have no idea. Try rerunning, maybe it was something transient. If not, I'll look again. > Add action in Chaos Monkey to restart Active Namenode > - > > Key: HBASE-19036 > URL: https://issues.apache.org/jira/browse/HBASE-19036 > Project: HBase > Issue Type: Improvement >Reporter: Monani Mihir >Assignee: Monani Mihir >Priority: Minor > Attachments: HBASE-19036.branch-1.001.patch, > HBASE-19036.branch-1.001.patch, HBASE-19036.branch-1.002.patch, > HBASE-19036.branch-1.002.patch, HBASE-19036.branch-1.003.patch, > HBASE-19036.branch-1.004.patch, HBASE-19036.master.001.patch, > HBASE-19036.master.002.patch, HBASE-19036.master.003.patch > > > Under hbase-it we have many actions related to DataNode, Zookeeper, HMaster > which gets use with Chaos Monkey and they are useful in testing . Having > action which restart Active Namenode would be useful too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20970) Update hadoop check versions in hbase-personality
[ https://issues.apache.org/jira/browse/HBASE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565495#comment-16565495 ] stack commented on HBASE-20970: --- I pushed the .001 patch with its update to refguide over on HBASE-20937. > Update hadoop check versions in hbase-personality > - > > Key: HBASE-20970 > URL: https://issues.apache.org/jira/browse/HBASE-20970 > Project: HBase > Issue Type: Bug > Components: build >Reporter: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-20970.branch-2.0.001.patch, > HBASE-20970.master.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20970) Update hadoop check versions in hbase-personality
[ https://issues.apache.org/jira/browse/HBASE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20970: -- Fix Version/s: (was: 2.0.2) > Update hadoop check versions in hbase-personality > - > > Key: HBASE-20970 > URL: https://issues.apache.org/jira/browse/HBASE-20970 > Project: HBase > Issue Type: Bug > Components: build >Reporter: Duo Zhang >Priority: Major > Fix For: 3.0.0, 2.2.0, 2.1.1 > > Attachments: HBASE-20970.branch-2.0.001.patch, > HBASE-20970.master.001.patch > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (HBASE-20937) Update the support matrix in our ref guide about the recent hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-20937. --- Resolution: Fixed Assignee: stack Hadoop Flags: Reviewed This is the patch I pushed. Got a +1 on it over in HBASE-20970 where it was named HBASE-20970.master.001.patch. > Update the support matrix in our ref guide about the recent hadoop releases > --- > > Key: HBASE-20937 > URL: https://issues.apache.org/jira/browse/HBASE-20937 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Duo Zhang >Assignee: stack >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > > > Copied from HBASE-20538 "Upgrade our hadoop versions to 2.7.7 and 3.0.3" and > from HBASE-20970 > Apache9 Duo Zhang added a comment - 6 days ago > I think we should mark 2.7.x before 2.7.7 as 'Not Supported' due to the JDK > issue? We only support jdk8 for 2.0 or above. > Apache9 Duo Zhang added a comment - 6 days ago - Restricted to Committers > And IIRC there is a security issue before 2.7.7 so it is important to drop > the support and let users upgrade to 2.7.7? > Apache9 Duo Zhang added a comment - 6 days ago > Also upgrade hadoop3 dependency to 3.0.3 which contains HADOOP-15473. > How does this issue relate to HBASE-20937? > Do we support 3.0.3 now? > Actually no. We do not support any 3.0.x releases due to the YARN issue > YARN-7190. But at least it could let us add back the ignored security UT. > There is still no production ready 3.1.x release... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (HBASE-20937) Update the support matrix in our ref guide about the recent hadoop releases
[ https://issues.apache.org/jira/browse/HBASE-20937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-20937: -- Attachment: 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > Update the support matrix in our ref guide about the recent hadoop releases > --- > > Key: HBASE-20937 > URL: https://issues.apache.org/jira/browse/HBASE-20937 > Project: HBase > Issue Type: Task > Components: documentation >Reporter: Duo Zhang >Priority: Major > Fix For: 3.0.0 > > Attachments: > 0001-HBASE-20937-Update-the-support-matrix-in-our-ref-gui.patch > > > Copied from HBASE-20538 "Upgrade our hadoop versions to 2.7.7 and 3.0.3" and > from HBASE-20970 > Apache9 Duo Zhang added a comment - 6 days ago > I think we should mark 2.7.x before 2.7.7 as 'Not Supported' due to the JDK > issue? We only support jdk8 for 2.0 or above. > Apache9 Duo Zhang added a comment - 6 days ago - Restricted to Committers > And IIRC there is a security issue before 2.7.7 so it is important to drop > the support and let users upgrade to 2.7.7? > Apache9 Duo Zhang added a comment - 6 days ago > Also upgrade hadoop3 dependency to 3.0.3 which contains HADOOP-15473. > How does this issue relate to HBASE-20937? > Do we support 3.0.3 now? > Actually no. We do not support any 3.0.x releases due to the YARN issue > YARN-7190. But at least it could let us add back the ignored security UT. > There is still no production ready 3.1.x release... -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (HBASE-20970) Update hadoop check versions in hbase-personality
[
https://issues.apache.org/jira/browse/HBASE-20970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16565478#comment-16565478
]
Hadoop QA commented on HBASE-20970:
---
| (/) *{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:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
4s{color} | {color:blue} Shelldocs was not available. {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} branch-2.0 Compile Tests {color} ||
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
1s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
10s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 0m 38s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f01af0 |
| JIRA Issue | HBASE-20970 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12933930/HBASE-20970.branch-2.0.001.patch
|
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux 3c0a7791983f 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 | branch-2.0 / 7bb867788a |
| maven | version: Apache Maven 3.5.4
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| shellcheck | v0.4.4 |
| Max. process+thread count | 42 (vs. ulimit of 1) |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/13884/console |
| Powered by | Apache Yetus 0.7.0 http://yetus.apache.org |
This message was automatically generated.
> Update hadoop check versions in hbase-personality
> -
>
> Key: HBASE-20970
> URL: https://issues.apache.org/jira/browse/HBASE-20970
> Project: HBase
> Issue Type: Bug
> Components: build
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.0.2, 2.2.0, 2.1.1
>
> Attachments: HBASE-20970.branch-2.0.001.patch,
> HBASE-20970.master.001.patch
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
