[jira] [Commented] (HBASE-18083) Make large/small file clean thread number configurable in HFileCleaner
[ https://issues.apache.org/jira/browse/HBASE-18083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077644#comment-16077644 ] Yu Li commented on HBASE-18083: --- IIRC, HadoopQA will report "overall 1" if no new warnings introduced by patch, no matter whether there exists warnings in current code base, but it seems the rule has changed... [~ashish singhi] [~chia7712] > Make large/small file clean thread number configurable in HFileCleaner > -- > > Key: HBASE-18083 > URL: https://issues.apache.org/jira/browse/HBASE-18083 > Project: HBase > Issue Type: Bug >Reporter: Yu Li >Assignee: Yu Li > Fix For: 3.0.0 > > Attachments: HBASE-18083.patch, HBASE-18083.v2.patch, > HBASE-18083.v3.patch > > > Currently we have only one thread for both large and small file cleaning, but > when write pressure is huge we might need more cleaner threads, so we need to > make the thread number configurable. > We observed more than 1.8PB data in archive directory online due to business > access rate change, and this proposal is one of the necessary changes > required. > Default value of the configurations would still be left to 1 to keep low > pressure to NN for normal case. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077596#comment-16077596 ] Guanghao Zhang commented on HBASE-17056: bq. It works if you cd hbase-server? Yes, It works after cd hbase-server to run it. Thanks. > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077595#comment-16077595
]
Hadoop QA commented on HBASE-18327:
---
| (/) *{color:green} 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: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:green} 1{color} | {color:green} shellcheck {color} | {color:green} 0m
5s{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:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
31m 52s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:green} 1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 32m 33s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12876025/HBASE-18327.2.patch |
| Optional Tests | asflicense shellcheck shelldocs |
| uname | Linux 7fd581506a6a 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 68436c9 |
| shellcheck | v0.4.6 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7558/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch,
> HBASE-18327.2.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077567#comment-16077567
]
Hadoop QA commented on HBASE-18327:
---
(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at
https://builds.apache.org/job/PreCommit-HBASE-Build/7558/console in case of
problems.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch,
> HBASE-18327.2.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17908) Upgrade guava
[ https://issues.apache.org/jira/browse/HBASE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17908: -- Attachment: HBASE-17908.master.022.patch > Upgrade guava > - > > Key: HBASE-17908 > URL: https://issues.apache.org/jira/browse/HBASE-17908 > Project: HBase > Issue Type: Sub-task > Components: dependencies >Reporter: Balazs Meszaros >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: 0001-HBASE-17908-Upgrade-guava.022.patch, > HBASE-17908.master.001.patch, HBASE-17908.master.002.patch, > HBASE-17908.master.003.patch, HBASE-17908.master.004.patch, > HBASE-17908.master.005.patch, HBASE-17908.master.006.patch, > HBASE-17908.master.007.patch, HBASE-17908.master.008.patch, > HBASE-17908.master.009.patch, HBASE-17908.master.010.patch, > HBASE-17908.master.011.patch, HBASE-17908.master.012.patch, > HBASE-17908.master.013.patch, HBASE-17908.master.013.patch, > HBASE-17908.master.014.patch, HBASE-17908.master.015.patch, > HBASE-17908.master.015.patch, HBASE-17908.master.016.patch, > HBASE-17908.master.017.patch, HBASE-17908.master.018.patch, > HBASE-17908.master.019.patch, HBASE-17908.master.020.patch, > HBASE-17908.master.021.patch, HBASE-17908.master.021.patch, > HBASE-17908.master.022.patch > > > Currently we are using guava 12.0.1, but the latest version is 21.0. > Upgrading guava is always a hassle because it is not always backward > compatible with itself. > Currently I think there are to approaches: > 1. Upgrade guava to the newest version (21.0) and shade it. > 2. Upgrade guava to a version which does not break or builds (15.0). > If we can update it, some dependencies should be removed: > commons-collections, commons-codec, ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17922) TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
[
https://issues.apache.org/jira/browse/HBASE-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077560#comment-16077560
]
Mike Drob commented on HBASE-17922:
---
Yes, {{hbase.regionserver.hostname}} is only used by HRegionServer (and in
tests).
> TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
> -
>
> Key: HBASE-17922
> URL: https://issues.apache.org/jira/browse/HBASE-17922
> Project: HBase
> Issue Type: Sub-task
> Components: hadoop3
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-2
>
> Attachments: HBASE-17922.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 126.363 sec
> <<< FAILURE! - in
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> testRegionServerHostname(org.apache.hadoop.hbase.regionserver.TestRegionServerHostname)
> Time elapsed: 120.029 sec <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 12
> milliseconds
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:221)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:405)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:225)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:94)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1123)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:1077)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:948)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:942)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname.testRegionServerHostname(TestRegionServerHostname.java:88)
> Results :
> Tests in error:
> TestRegionServerHostname.testRegionServerHostname:88 » TestTimedOut test
> timed...
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18327:
Attachment: HBASE-18327.2.patch
Attaching new version of the patch created without using the {{--stdout}} arg
to format-patch, so the generated file works with {{git am}}.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch,
> HBASE-18327.2.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18295) The result contains the cells across different rows
[ https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18295: --- Status: Patch Available (was: Open) > The result contains the cells across different rows > > > Key: HBASE-18295 > URL: https://issues.apache.org/jira/browse/HBASE-18295 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 1.3.2, 2.0.0-alpha-2 > > Attachments: HBASE-18295.branch-1.3.v0.patch, > HBASE-18295.branch-1.v0.patch, HBASE-18295.branch-1.v1.patch, > HBASE-18295.v0.patch, HBASE-18295.v1.patch, HBASE-18295.v2.patch, > HBASE-18295.v2.patch > > > From the [flaky > dashboard|https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html] > If we use the cell which won't be flushed into disk as the top cell to reopen > the scanners, the new top cell will change. If the new top cell is in > different row, the matcher will reset, and then matcher will accept the new > top cell... > The TestStore# testFlushBeforeCompletingScan reproduces the bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18295) The result contains the cells across different rows
[ https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18295: --- Status: Open (was: Patch Available) > The result contains the cells across different rows > > > Key: HBASE-18295 > URL: https://issues.apache.org/jira/browse/HBASE-18295 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 1.3.2, 2.0.0-alpha-2 > > Attachments: HBASE-18295.branch-1.3.v0.patch, > HBASE-18295.branch-1.v0.patch, HBASE-18295.branch-1.v1.patch, > HBASE-18295.v0.patch, HBASE-18295.v1.patch, HBASE-18295.v2.patch, > HBASE-18295.v2.patch > > > From the [flaky > dashboard|https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html] > If we use the cell which won't be flushed into disk as the top cell to reopen > the scanners, the new top cell will change. If the new top cell is in > different row, the matcher will reset, and then matcher will accept the new > top cell... > The TestStore# testFlushBeforeCompletingScan reproduces the bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18295) The result contains the cells across different rows
[ https://issues.apache.org/jira/browse/HBASE-18295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai updated HBASE-18295: --- Attachment: HBASE-18295.branch-1.v1.patch > The result contains the cells across different rows > > > Key: HBASE-18295 > URL: https://issues.apache.org/jira/browse/HBASE-18295 > Project: HBase > Issue Type: Bug >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 1.3.2, 2.0.0-alpha-2 > > Attachments: HBASE-18295.branch-1.3.v0.patch, > HBASE-18295.branch-1.v0.patch, HBASE-18295.branch-1.v1.patch, > HBASE-18295.v0.patch, HBASE-18295.v1.patch, HBASE-18295.v2.patch, > HBASE-18295.v2.patch > > > From the [flaky > dashboard|https://builds.apache.org/job/HBASE-Find-Flaky-Tests/lastSuccessfulBuild/artifact/dashboard.html] > If we use the cell which won't be flushed into disk as the top cell to reopen > the scanners, the new top cell will change. If the new top cell is in > different row, the matcher will reset, and then matcher will accept the new > top cell... > The TestStore# testFlushBeforeCompletingScan reproduces the bug. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18241) Change client.Table, client.Admin, Region, and Store to not use HTableDescriptor or HColumnDescriptor
[
https://issues.apache.org/jira/browse/HBASE-18241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18241:
---
Status: Patch Available (was: Open)
> Change client.Table, client.Admin, Region, and Store to not use
> HTableDescriptor or HColumnDescriptor
> -
>
> Key: HBASE-18241
> URL: https://issues.apache.org/jira/browse/HBASE-18241
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Biju Nair
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18241.v0.patch, HBASE-18241.v1.patch,
> HBASE-18241.v2.patch, HBASE-18241.v2.patch, HBASE-18241.v3.patch,
> HBASE-18241.v3.patch, HBASE-18241.v4.patch, HBASE-18241.v5.patch,
> HBASE-18241.v5.patch
>
>
> {{HTableDescriptor}} is deprecated and scheduled to be removed in 3.0. But
> [client.Table|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java#L69]
> and
> [client.Admin|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java#L198]
> method {{getTableDescriptor}} returns {{HTableDescriptor}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18241) Change client.Table, client.Admin, Region, and Store to not use HTableDescriptor or HColumnDescriptor
[
https://issues.apache.org/jira/browse/HBASE-18241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18241:
---
Attachment: HBASE-18241.v5.patch
retry v5
> Change client.Table, client.Admin, Region, and Store to not use
> HTableDescriptor or HColumnDescriptor
> -
>
> Key: HBASE-18241
> URL: https://issues.apache.org/jira/browse/HBASE-18241
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Biju Nair
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18241.v0.patch, HBASE-18241.v1.patch,
> HBASE-18241.v2.patch, HBASE-18241.v2.patch, HBASE-18241.v3.patch,
> HBASE-18241.v3.patch, HBASE-18241.v4.patch, HBASE-18241.v5.patch,
> HBASE-18241.v5.patch
>
>
> {{HTableDescriptor}} is deprecated and scheduled to be removed in 3.0. But
> [client.Table|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java#L69]
> and
> [client.Admin|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java#L198]
> method {{getTableDescriptor}} returns {{HTableDescriptor}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17931) Assign system tables to servers with highest version
[ https://issues.apache.org/jira/browse/HBASE-17931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077551#comment-16077551 ] stack commented on HBASE-17931: --- Try again [~yangzhe1991] Perhaps HBASE-17908 caused havoc... I reverted for the moment. > Assign system tables to servers with highest version > > > Key: HBASE-17931 > URL: https://issues.apache.org/jira/browse/HBASE-17931 > Project: HBase > Issue Type: Bug > Components: Region Assignment, scan >Reporter: Phil Yang >Assignee: Phil Yang >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 2.0.0-alpha-2 > > Attachments: HBASE-17931.branch-1.v01.patch, > HBASE-17931.branch-1.v02.patch, HBASE-17931.branch-1.v03.patch, > HBASE-17931.branch-1.v04.patch, HBASE-17931.branch-1.v04.patch, > HBASE-17931.branch-1.v05.patch, HBASE-17931.branch-1.v05.patch, > HBASE-17931.branch-1.v06.patch, HBASE-17931.v01.patch, HBASE-17931.v02.patch, > HBASE-17931.v03.patch, HBASE-17931.v04.patch, HBASE-17931.v04.patch, > HBASE-17931.v05.patch > > > In branch-1 and master we have some improvement and new features on scanning > which is not compatible. > A client of old version to a server of new version is compatible (must be a > bug if not, maybe need some test?). > A client of new version may not be able to read from a server of old version > correctly (because of scan limit, moreResults flag, etc), which is ok for > major/minor upgrade and we can tell users to upgrade server before upgrading > client. But RS also use scan to read meta. If meta table is in RS of old > version, all RSs of new version may have trouble while scanning meta table. > So we should make sure meta table always in servers of new version. Force > meta table in Master and upgrade Master first, or assign meta table in region > servers with latest version? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17056: -- Priority: Critical (was: Major) > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18241) Change client.Table, client.Admin, Region, and Store to not use HTableDescriptor or HColumnDescriptor
[
https://issues.apache.org/jira/browse/HBASE-18241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18241:
---
Status: Open (was: Patch Available)
> Change client.Table, client.Admin, Region, and Store to not use
> HTableDescriptor or HColumnDescriptor
> -
>
> Key: HBASE-18241
> URL: https://issues.apache.org/jira/browse/HBASE-18241
> Project: HBase
> Issue Type: Task
> Components: Client
>Reporter: Biju Nair
>Assignee: Chia-Ping Tsai
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-18241.v0.patch, HBASE-18241.v1.patch,
> HBASE-18241.v2.patch, HBASE-18241.v2.patch, HBASE-18241.v3.patch,
> HBASE-18241.v3.patch, HBASE-18241.v4.patch, HBASE-18241.v5.patch
>
>
> {{HTableDescriptor}} is deprecated and scheduled to be removed in 3.0. But
> [client.Table|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Table.java#L69]
> and
> [client.Admin|https://github.com/apache/hbase/blob/a66d491892514fd4a188d6ca87d6260d8ae46184/hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java#L198]
> method {{getTableDescriptor}} returns {{HTableDescriptor}}.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reopened HBASE-17056: --- Reverting for now. I am away from computer for a while so unable to provide the support to get over any issues this large commit generates. Will try again later when build settles. It is failing currently w/ OOMEs. > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077548#comment-16077548 ] stack commented on HBASE-17056: --- [~zghaobac] Reverted for the moment sir. Ditto [~chia7712] Will try again later. > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077543#comment-16077543 ] Hudson commented on HBASE-18329: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3329 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3329/]) HBASE-18329 updated links in config guide to point to java 8 references (tedyu: rev 68436c9bbaefa78704b30315713de94dd991fda1) * (edit) src/main/asciidoc/_chapters/hbase-default.adoc * (edit) src/main/asciidoc/_chapters/configuration.adoc > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-17922) TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
[
https://issues.apache.org/jira/browse/HBASE-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077541#comment-16077541
]
Appy edited comment on HBASE-17922 at 7/7/17 4:08 AM:
--
bq. It looks like something during the aborted startup in MiniHBaseCluster is
poisoning the future runs. I wasn't able to figure out exactly what it is, but
we can run the test against the HRegionServer directly instead and get the same
coverage without breaking other tests in the class. Unless the point was to
test the TEST_UTIL, which I don't think it is.
The point is definitely not to test TestUtil, but then,
TestUtil.startMiniCluster() runs a lot more non-test code than just {{new
HRegionServer()}}. So replacing two is not same.
Howerver, if you are saying we don't really need miniCluster to test this
functionality since the config being changed in test
(hbase.regionserver.hostname) is limited to HRegionServer, then i buy it.
+1
was (Author: appy):
bq. It looks like something during the aborted startup in MiniHBaseCluster is
poisoning the future runs. I wasn't able to figure out exactly what it is, but
we can run the test against the HRegionServer directly instead and get the same
coverage without breaking other tests in the class. Unless the point was to
test the TEST_UTIL, which I don't think it is.
The point is definitely not to test TestUtil, but then,
TestUtil.startMiniCluster() runs a lot more non-test code than just {{new
HRegionServer()}}. So replacing two is not same.
Howerver, if you are saying we don't really need miniCluster to test this
functionality since the config being changed in test
(hbase.regionserver.hostname) is limited to HRegionServer, then i buy it.
1
> TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
> -
>
> Key: HBASE-17922
> URL: https://issues.apache.org/jira/browse/HBASE-17922
> Project: HBase
> Issue Type: Sub-task
> Components: hadoop3
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-2
>
> Attachments: HBASE-17922.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 126.363 sec
> <<< FAILURE! - in
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> testRegionServerHostname(org.apache.hadoop.hbase.regionserver.TestRegionServerHostname)
> Time elapsed: 120.029 sec <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 12
> milliseconds
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:221)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:405)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:225)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:94)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1123)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:1077)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:948)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:942)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname.testRegionServerHostname(TestRegionServerHostname.java:88)
> Results :
> Tests in error:
> TestRegionServerHostname.testRegionServerHostname:88 » TestTimedOut test
> timed...
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17922) TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
[
https://issues.apache.org/jira/browse/HBASE-17922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077541#comment-16077541
]
Appy commented on HBASE-17922:
--
bq. It looks like something during the aborted startup in MiniHBaseCluster is
poisoning the future runs. I wasn't able to figure out exactly what it is, but
we can run the test against the HRegionServer directly instead and get the same
coverage without breaking other tests in the class. Unless the point was to
test the TEST_UTIL, which I don't think it is.
The point is definitely not to test TestUtil, but then,
TestUtil.startMiniCluster() runs a lot more non-test code than just {{new
HRegionServer()}}. So replacing two is not same.
Howerver, if you are saying we don't really need miniCluster to test this
functionality since the config being changed in test
(hbase.regionserver.hostname) is limited to HRegionServer, then i buy it.
1
> TestRegionServerHostname always fails against hadoop 3.0.0-alpha2
> -
>
> Key: HBASE-17922
> URL: https://issues.apache.org/jira/browse/HBASE-17922
> Project: HBase
> Issue Type: Sub-task
> Components: hadoop3
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Mike Drob
> Fix For: 2.0.0-alpha-2
>
> Attachments: HBASE-17922.patch
>
>
> {code}
> Running org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 126.363 sec
> <<< FAILURE! - in
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname
> testRegionServerHostname(org.apache.hadoop.hbase.regionserver.TestRegionServerHostname)
> Time elapsed: 120.029 sec <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 12
> milliseconds
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.hadoop.hbase.util.JVMClusterUtil.startup(JVMClusterUtil.java:221)
> at
> org.apache.hadoop.hbase.LocalHBaseCluster.startup(LocalHBaseCluster.java:405)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.init(MiniHBaseCluster.java:225)
> at
> org.apache.hadoop.hbase.MiniHBaseCluster.(MiniHBaseCluster.java:94)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniHBaseCluster(HBaseTestingUtility.java:1123)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:1077)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:948)
> at
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster(HBaseTestingUtility.java:942)
> at
> org.apache.hadoop.hbase.regionserver.TestRegionServerHostname.testRegionServerHostname(TestRegionServerHostname.java:88)
> Results :
> Tests in error:
> TestRegionServerHostname.testRegionServerHostname:88 » TestTimedOut test
> timed...
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077538#comment-16077538 ] stack commented on HBASE-17056: --- It works if you cd hbase-server? > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17931) Assign system tables to servers with highest version
[ https://issues.apache.org/jira/browse/HBASE-17931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077537#comment-16077537 ] Phil Yang commented on HBASE-17931: --- This test in the version before this commit also failed > Assign system tables to servers with highest version > > > Key: HBASE-17931 > URL: https://issues.apache.org/jira/browse/HBASE-17931 > Project: HBase > Issue Type: Bug > Components: Region Assignment, scan >Reporter: Phil Yang >Assignee: Phil Yang >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 2.0.0-alpha-2 > > Attachments: HBASE-17931.branch-1.v01.patch, > HBASE-17931.branch-1.v02.patch, HBASE-17931.branch-1.v03.patch, > HBASE-17931.branch-1.v04.patch, HBASE-17931.branch-1.v04.patch, > HBASE-17931.branch-1.v05.patch, HBASE-17931.branch-1.v05.patch, > HBASE-17931.branch-1.v06.patch, HBASE-17931.v01.patch, HBASE-17931.v02.patch, > HBASE-17931.v03.patch, HBASE-17931.v04.patch, HBASE-17931.v04.patch, > HBASE-17931.v05.patch > > > In branch-1 and master we have some improvement and new features on scanning > which is not compatible. > A client of old version to a server of new version is compatible (must be a > bug if not, maybe need some test?). > A client of new version may not be able to read from a server of old version > correctly (because of scan limit, moreResults flag, etc), which is ok for > major/minor upgrade and we can tell users to upgrade server before upgrading > client. But RS also use scan to read meta. If meta table is in RS of old > version, all RSs of new version may have trouble while scanning meta table. > So we should make sure meta table always in servers of new version. Force > meta table in Master and upgrade Master first, or assign meta table in region > servers with latest version? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18330) NPE in ReplicationZKLockCleanerChore
[
https://issues.apache.org/jira/browse/HBASE-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Minwoo Kang updated HBASE-18330:
Description:
While I am watching HMaster log, I found NullPointerException Logs.
This occurs every minute.
2017-07-06 09:05:02,579 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,585 ERROR [,1498445640728_ChoreService_2]
hbase.ScheduledChore: Caught error
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.cleaner.ReplicationZKLockCleanerChore.chore(ReplicationZKLockCleanerChore.java:80)
at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:185)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
org.apache.hadoop.hbase.JitterScheduledThreadPoolExecutorImpl$JitteredRunnableScheduledFuture.run(JitterScheduledThreadPoolExecutorImpl.java:110)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2017-07-06 09:05:02,585 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,586 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
Here is related code:
List replicators = queues.getListOfReplicators();
for (String replicator: replicators) {
was:
While I am watching HMaster log, I found NullPointerException Logs.
2017-07-06 09:05:02,579 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,585 ERROR [,1498445640728_ChoreService_2]
hbase.ScheduledChore: Caught error
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.cleaner.ReplicationZKLockCleanerChore.chore(ReplicationZKLockCleanerChore.java:80)
at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:185)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
org.apache.hadoop.hbase.JitterScheduledThreadPoolExecutorImpl$JitteredRunnableScheduledFuture.run(JitterScheduledThreadPoolExecutorImpl.java:110)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2017-07-06 09:05:02,585 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,586 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
Here is related code:
List replicators = queues.getListOfReplicators();
for (String replicator: replicators) {
> NPE in ReplicationZKLockCleanerChore
>
>
> Key: HBASE-18330
> URL: https://issues.apache.org/jira/browse/HBASE-18330
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.5
>Reporter: Minwoo Kang
>Priority: Minor
>
> While I am watching HMaster log, I found NullPointerException Logs.
> This occurs every minute.
>
> 2017-07-06 09:05:02,579 DEBUG [,1498445640728_ChoreService_1]
> cleaner.CleanerChore: Removing: hdfs://*** from archive
> 2017-07-06 09:05:02,585 ERROR [,1498445640728_ChoreService_2]
> hbase.ScheduledChore: Caught error
> java.lang.NullPointerException
> at
> org.apache.hadoop.hbase.master.cleaner.ReplicationZKLockCleanerChore.chore(ReplicationZKLockCleanerChore.java:80)
> at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:185)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at
>
[jira] [Created] (HBASE-18330) NPE in ReplicationZKLockCleanerChore
Minwoo Kang created HBASE-18330:
---
Summary: NPE in ReplicationZKLockCleanerChore
Key: HBASE-18330
URL: https://issues.apache.org/jira/browse/HBASE-18330
Project: HBase
Issue Type: Bug
Affects Versions: 1.2.5
Reporter: Minwoo Kang
Priority: Minor
While I am watching HMaster log, I found NullPointerException Logs.
2017-07-06 09:05:02,579 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,585 ERROR [,1498445640728_ChoreService_2]
hbase.ScheduledChore: Caught error
java.lang.NullPointerException
at
org.apache.hadoop.hbase.master.cleaner.ReplicationZKLockCleanerChore.chore(ReplicationZKLockCleanerChore.java:80)
at org.apache.hadoop.hbase.ScheduledChore.run(ScheduledChore.java:185)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at
org.apache.hadoop.hbase.JitterScheduledThreadPoolExecutorImpl$JitteredRunnableScheduledFuture.run(JitterScheduledThreadPoolExecutorImpl.java:110)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2017-07-06 09:05:02,585 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
2017-07-06 09:05:02,586 DEBUG [,1498445640728_ChoreService_1]
cleaner.CleanerChore: Removing: hdfs://*** from archive
Here is related code:
List replicators = queues.getListOfReplicators();
for (String replicator: replicators) {
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077533#comment-16077533 ] stack commented on HBASE-17056: --- @guanghao zhang Thanks for reporting... taking a look. > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18323) Remove multiple ACLs for the same user in kerberos
[
https://issues.apache.org/jira/browse/HBASE-18323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077523#comment-16077523
]
Shibin Zhang commented on HBASE-18323:
--
[~elserj] how about this way in ZKUtil.createAcl :
String[] superUsers =
zkw.getConfiguration().getStrings(Superusers.SUPERUSER_CONF_KEY);
String hbaseUser =
UserGroupInformation.getCurrentUser().getShortUserName();
if(!ArrayUtils.contains(superUsers,hbaseUser)){
acls.addAll(Ids.CREATOR_ALL_ACL);
}
> Remove multiple ACLs for the same user in kerberos
> --
>
> Key: HBASE-18323
> URL: https://issues.apache.org/jira/browse/HBASE-18323
> Project: HBase
> Issue Type: Bug
>Affects Versions: 1.2.0, 3.0.0
>Reporter: Shibin Zhang
>Priority: Minor
> Attachments: HBASE-18323.patch, HBASE-18323-V2.patch,
> HBASE-18323-V3.patch
>
>
> When deploy hbase in kerberos way ,there will be multiple acls in znode :
> 'world,'anyone
> : r
> 'sasl,'hbase
> : cdrwa
> 'sasl,'hbase
> : cdrwa
> I also see the related issue and apply the patch, like
> https://issues.apache.org/jira/browse/HBASE-17717
> but in my environment ,this situation still appear,
> After dig into the code , i found the reason in source code ZKUtil.createAcl
> is
> if (zkw.isClientReadable(node)) {
> LOG.error("isSecureZooKeeper user: clientReadable");
> acls.addAll(Ids.CREATOR_ALL_ACL);
> acls.addAll(Ids.READ_ACL_UNSAFE);
> } else {
> LOG.error("isSecureZooKeeper user: clientReadable no");
> acls.addAll(Ids.CREATOR_ALL_ACL);
> }
> acls.addAll(Ids.CREATOR_ALL_ACL);
>
> Id AUTH_IDS = new Id("auth", "");
> ArrayList CREATOR_ALL_ACL = new ArrayList(Collections.singletonList(new
> ACL(31, AUTH_IDS)));
> AUTH_IDS with "auth " will result current connection auth user add to
> znode acl ,
> so it will appear multiple acls for same users.
> I think this line of code we can remove :
> acls.addAll(Ids.CREATOR_ALL_ACL);
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-17908) Upgrade guava
[
https://issues.apache.org/jira/browse/HBASE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077521#comment-16077521
]
Hadoop QA commented on HBASE-17908:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 16m
40s{color} | {color:blue} Docker mode activated. {color} |
| {color:green} 1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green} 1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green} 1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 210 new or modified
test files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 2m
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 4m
59s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
30s{color} | {color:red} root in master failed. {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 5m
55s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 5m
10s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util hbase-assembly . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
29s{color} | {color:red} hbase-common in master has 2 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
47s{color} | {color:red} hbase-client in master has 4 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
22s{color} | {color:red} hbase-server in master has 10 extant Findbugs
warnings. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
30s{color} | {color:red} hbase-rest in master has 3 extant Findbugs warnings.
{color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 5m
42s{color} | {color:green} master passed {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} 8m
11s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
30s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 30s{color}
| {color:red} root in the patch failed. {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 6m
10s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 5m
30s{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
27s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 21s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util hbase-assembly . {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
36s{color} | {color:green} hbase-common generated 0 new 0 unchanged - 2 fixed
= 0 total (was 2) {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
22s{color} | {color:green} hbase-metrics-api in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
27s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
22s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
22s{color} | {color:green} hbase-metrics in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs
[jira] [Comment Edited] (HBASE-18319) Implement getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp methods
[ https://issues.apache.org/jira/browse/HBASE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077480#comment-16077480 ] Duo Zhang edited comment on HBASE-18319 at 7/7/17 3:20 AM: --- +1 was (Author: apache9): 1. > Implement > getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp > methods > --- > > Key: HBASE-18319 > URL: https://issues.apache.org/jira/browse/HBASE-18319 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18319.master.001.patch, > HBASE-18319.master.002.patch, HBASE-18319.master.003.patch, > HBASE-18319.master.004.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17931) Assign system tables to servers with highest version
[ https://issues.apache.org/jira/browse/HBASE-17931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077492#comment-16077492 ] Hudson commented on HBASE-17931: FAILURE: Integrated in Jenkins build HBASE-14070.HLC #8 (See [https://builds.apache.org/job/HBASE-14070.HLC/8/]) HBASE-17931 Assign system tables to servers with highest version (yangzhe1991: rev 75d2eca8ace0795bd55ea08b90a0fb784f73fed4) * (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/VersionInfo.java * (add) hbase-common/src/test/java/org/apache/hadoop/hbase/util/TestVersionInfo.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/RegionServerTracker.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/ServerManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockNoopMasterServices.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/assignment/AssignmentManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterServices.java > Assign system tables to servers with highest version > > > Key: HBASE-17931 > URL: https://issues.apache.org/jira/browse/HBASE-17931 > Project: HBase > Issue Type: Bug > Components: Region Assignment, scan >Reporter: Phil Yang >Assignee: Phil Yang >Priority: Blocker > Fix For: 3.0.0, 1.4.0, 2.0.0-alpha-2 > > Attachments: HBASE-17931.branch-1.v01.patch, > HBASE-17931.branch-1.v02.patch, HBASE-17931.branch-1.v03.patch, > HBASE-17931.branch-1.v04.patch, HBASE-17931.branch-1.v04.patch, > HBASE-17931.branch-1.v05.patch, HBASE-17931.branch-1.v05.patch, > HBASE-17931.branch-1.v06.patch, HBASE-17931.v01.patch, HBASE-17931.v02.patch, > HBASE-17931.v03.patch, HBASE-17931.v04.patch, HBASE-17931.v04.patch, > HBASE-17931.v05.patch > > > In branch-1 and master we have some improvement and new features on scanning > which is not compatible. > A client of old version to a server of new version is compatible (must be a > bug if not, maybe need some test?). > A client of new version may not be able to read from a server of old version > correctly (because of scan limit, moreResults flag, etc), which is ok for > major/minor upgrade and we can tell users to upgrade server before upgrading > client. But RS also use scan to read meta. If meta table is in RS of old > version, all RSs of new version may have trouble while scanning meta table. > So we should make sure meta table always in servers of new version. Force > meta table in Master and upgrade Master first, or assign meta table in region > servers with latest version? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18002) Investigate why bucket cache filling up in file mode in an exisiting file is slower
[ https://issues.apache.org/jira/browse/HBASE-18002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077491#comment-16077491 ] Hudson commented on HBASE-18002: FAILURE: Integrated in Jenkins build HBASE-14070.HLC #8 (See [https://builds.apache.org/job/HBASE-14070.HLC/8/]) HBASE-18002 Investigate why bucket cache filling up in file mode in an (ramkrishna: rev 50bb04572371e68726a9176cdcb0668e3fd74feb) * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/FileIOEngine.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/bucket/TestFileIOEngine.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/bucket/BucketCache.java > Investigate why bucket cache filling up in file mode in an exisiting file is > slower > > > Key: HBASE-18002 > URL: https://issues.apache.org/jira/browse/HBASE-18002 > Project: HBase > Issue Type: Sub-task > Components: BucketCache >Affects Versions: 2.0.0 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18002_1.patch, HBASE-18002_1.patch, > HBASE-18002.patch > > > This issue was observed when we recently did some tests with SSD based bucket > cache. Similar thing was also reported by @stack and [~danielpol] while doing > some of these bucket cache related testing. > When we try to preload a bucket cache (in file mode) with a new file the > bucket cache fills up quite faster and there not much 'failedBlockAdditions'. > But when the same bucket cache is filled up with a preexisitng file ( that > had already some entries filled up) this time it has more > 'failedBlockAdditions' and the cache does not fill up faster. Investigate why > this happens. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077490#comment-16077490 ] Hudson commented on HBASE-17056: FAILURE: Integrated in Jenkins build HBASE-14070.HLC #8 (See [https://builds.apache.org/job/HBASE-14070.HLC/8/]) HBASE-17056 Remove checked in PB generated files Selective add of (stack: rev df93c13fd21a3f34aa3851893d715cbc4edb555b) * (delete) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java * (delete) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/CellProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/FloatValue.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/MessageLiteToString.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Type.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/RpcUtil.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/AnyOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/GeneratedMessage.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/MixinOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/TextFormatParseInfoTree.java * (delete) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/WALProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/generated/MapReduceProtos.java * (delete) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/protobuf/generated/AggregateProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/generated/WALProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/UnmodifiableLazyStringList.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/EnumValueOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Int32Value.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Struct.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/AbstractMessage.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/StringValue.java * (edit) hbase-spark/pom.xml * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Int32ValueOrBuilder.java * (delete) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/protobuf/generated/CellMessage.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Descriptors.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/generated/ClusterStatusProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/MapFieldLite.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/SingleFieldBuilderV3.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/ByteBufferWriter.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/RepeatedFieldBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/protobuf/generated/FSProtos.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Internal.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/Int64ValueOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/BoolValueOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/RpcController.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/GeneratedMessageLite.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/UInt32ValueOrBuilder.java * (delete) hbase-protocol-shaded/src/main/java/org/apache/hadoop/hbase/shaded/com/google/protobuf/MessageLiteOrBuilder.java * (delete) hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/RPCProtos.java * (delete) hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/protobuf/generated/TableListMessage.java * (delete)
[jira] [Commented] (HBASE-18325) Disable flakey TestMasterProcedureWalLease
[ https://issues.apache.org/jira/browse/HBASE-18325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077489#comment-16077489 ] Hudson commented on HBASE-18325: FAILURE: Integrated in Jenkins build HBASE-14070.HLC #8 (See [https://builds.apache.org/job/HBASE-14070.HLC/8/]) HBASE-18325 Disable flakey TestMasterProcedureWalLease (stack: rev 172c662034dddca0592740eb94e81c8c2388a2b1) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestMasterProcedureWalLease.java > Disable flakey TestMasterProcedureWalLease > -- > > Key: HBASE-18325 > URL: https://issues.apache.org/jira/browse/HBASE-18325 > Project: HBase > Issue Type: Bug > Components: test >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14070) Hybrid Logical Clocks for HBase
[ https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077488#comment-16077488 ] Hudson commented on HBASE-14070: FAILURE: Integrated in Jenkins build HBASE-14070.HLC #8 (See [https://builds.apache.org/job/HBASE-14070.HLC/8/]) HBASE-14070 - Core HLC (stack: rev 9fe94c11690891eed6470fdb0b9bfcfc9e95a888) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/HTableDescriptor.java * (add) hbase-common/src/main/java/org/apache/hadoop/hbase/Clock.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-client/src/test/java/org/apache/hadoop/hbase/TestInterfaceAudienceAnnotations.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestWALLockup.java * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/TestClockWithCluster.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionSplitPolicy.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/security/access/AccessController.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestCompactingMemStore.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestCoprocessorScanPolicy.java * (add) hbase-common/src/main/java/org/apache/hadoop/hbase/TimestampType.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegionReplayEvents.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/master/MockRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/querymatcher/ScanQueryMatcher.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/master/procedure/ModifyTableProcedure.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/TableDescriptorBuilder.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestTableName.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/querymatcher/DropDeletesCompactionScanQueryMatcher.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreScanner.java * (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/SettableTimestamp.java * (add) hbase-common/src/test/java/org/apache/hadoop/hbase/TestTimestampType.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestDefaultMemStore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLWithMultipleVersions.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Region.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestIncrementTimeRange.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StoreScanner.java * (add) hbase-common/src/main/java/org/apache/hadoop/hbase/ClockType.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestCopyTable.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestHFileOutputFormat2.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/AbstractTestWALReplay.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/MockRegionServerServices.java * (add) hbase-common/src/test/java/org/apache/hadoop/hbase/TestClock.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestHRegion.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/TableDescriptor.java Revert "HBASE-14070 - Core HLC" Revert a push too-early (stack: rev c5abb6cabb312a424dc14aa77055339fe5cac5f7) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/util/TestCoprocessorScanPolicy.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/wal/AbstractTestWALReplay.java * (delete) hbase-common/src/test/java/org/apache/hadoop/hbase/TestClock.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestStoreScanner.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerServices.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestCellACLWithMultipleVersions.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/querymatcher/DropDeletesCompactionScanQueryMatcher.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestRegionSplitPolicy.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * (edit)
[jira] [Commented] (HBASE-18319) Implement getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp methods
[ https://issues.apache.org/jira/browse/HBASE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077480#comment-16077480 ] Duo Zhang commented on HBASE-18319: --- 1. > Implement > getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp > methods > --- > > Key: HBASE-18319 > URL: https://issues.apache.org/jira/browse/HBASE-18319 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18319.master.001.patch, > HBASE-18319.master.002.patch, HBASE-18319.master.003.patch, > HBASE-18319.master.004.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14135) HBase Backup/Restore Phase 3: Merge backup images
[
https://issues.apache.org/jira/browse/HBASE-14135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077479#comment-16077479
]
Devaraj Das commented on HBASE-14135:
-
bq. Originally it was Service, then - Task, now is Job. What do you suggest,
stack?
How about _process_? Seems generic enough to capture MR Job among other
possibilities.. Stack?
> HBase Backup/Restore Phase 3: Merge backup images
> -
>
> Key: HBASE-14135
> URL: https://issues.apache.org/jira/browse/HBASE-14135
> Project: HBase
> Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: HBASE-7912
>
> Attachments: HBASE-14135-v1.patch, HBASE-14135-v3.patch
>
>
> User can merge incremental backup images into single incremental backup image.
> # Merge supports only incremental images
> # Merge supports only images for the same backup destinations
> Command:
> {code}
> hbase backup merge image1,image2,..imageK
> {code}
> Example:
> {code}
> hbase backup merge backup_143126764557,backup_143126764456
> {code}
> When operation is complete, only the most recent backup image will be kept
> (in above example - backup_143126764557) as a merged backup image, all other
> images will be deleted from both: file system and backup system tables,
> corresponding backup manifest for the merged backup image will be updated to
> remove dependencies from deleted images. Merged backup image will contains
> all the data from original image and from deleted images.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18319) Implement getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp methods
[ https://issues.apache.org/jira/browse/HBASE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-18319: --- Attachment: HBASE-18319.master.004.patch > Implement > getClusterStatus/getRegionLoad/getCompactionState/getLastMajorCompactionTimestamp > methods > --- > > Key: HBASE-18319 > URL: https://issues.apache.org/jira/browse/HBASE-18319 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-18319.master.001.patch, > HBASE-18319.master.002.patch, HBASE-18319.master.003.patch, > HBASE-18319.master.004.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Reopened] (HBASE-16574) Add backup / restore feature to refguide
[ https://issues.apache.org/jira/browse/HBASE-16574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu reopened HBASE-16574: Looks like this missed the merge to master branch. > Add backup / restore feature to refguide > > > Key: HBASE-16574 > URL: https://issues.apache.org/jira/browse/HBASE-16574 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Frank Welsch > Labels: backup > Fix For: 2.0.0 > > Attachments: Backup-and-Restore-Apache_19Sep2016.pdf, > HBASE-16574.001.patch, HBASE-16574.002.patch, hbase_reference_guide.v1.pdf > > > This issue is to add backup / restore feature description to hbase refguide. > The description should cover: > scenarios where backup / restore is used > backup / restore commands and sample usage > considerations in setup -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[
https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077445#comment-16077445
]
Guanghao Zhang commented on HBASE-17056:
"mvn clean install -DskipTests" success. But then i got a error when run "mvn
test -Dtest=TestAsyncTableAdminApi".
{code}
[INFO] Running org.apache.hadoop.hbase.client.TestAsyncTableAdminApi
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.922 s
<<< FAILURE! - in org.apache.hadoop.hbase.client.TestAsyncTableAdminApi
[ERROR] org.apache.hadoop.hbase.client.TestAsyncTableAdminApi Time elapsed:
4.922 s <<< ERROR!
java.lang.NoClassDefFoundError: com/google/protobuf/GeneratedMessageV3
Caused by: java.lang.ClassNotFoundException:
com.google.protobuf.GeneratedMessageV3
{code}
I need do something else now?
> Remove checked in PB generated files
> -
>
> Key: HBASE-17056
> URL: https://issues.apache.org/jira/browse/HBASE-17056
> Project: HBase
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Enis Soztutar
>Assignee: stack
> Fix For: 2.0.0
>
> Attachments:
> 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch,
> HBASE-17056.master.001.patch, HBASE-17056.master.002.patch,
> HBASE-17056.master.003.patch
>
>
> Now that we have the new PB maven plugin, there is no need to have the PB
> files checked in to the repo. The reason we did that was to ease up developer
> env setup.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18329: --- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Thanks for the patch. > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077441#comment-16077441 ] Artem Ervits commented on HBASE-18329: -- this is a documentation patch, no tests necessary > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077440#comment-16077440 ] stack commented on HBASE-17056: --- Is this different now? All prereq for test have to built? > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18324) [hbase-thirdparty] Tooling to prevent commits that mistakenly make use of unshaded protobuf/guava/etc.
[ https://issues.apache.org/jira/browse/HBASE-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077439#comment-16077439 ] stack commented on HBASE-18324: --- 'com.google' and 'io.netty' will get 99% > [hbase-thirdparty] Tooling to prevent commits that mistakenly make use of > unshaded protobuf/guava/etc. > -- > > Key: HBASE-18324 > URL: https://issues.apache.org/jira/browse/HBASE-18324 > Project: HBase > Issue Type: Bug >Reporter: stack > > Chatting w/ [~mdrob], he brought up the question of what if a dev makes use > of unshaded protobuf or guava? Afterall, the old jars (pb2.5 and hadoops > guava12.0 or whatever) are still on the CLASSPATH because upstream depends on > them. > We could add a check as part of prebuild. It would complain if use of > com.google instead of org.apache.hadoop.hbase.shaded.com.google. But even > then, there are cases where com.google is legit (coprocessor endpoints) so it > would have to let these pass. > TODO. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17056) Remove checked in PB generated files
[ https://issues.apache.org/jira/browse/HBASE-17056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077437#comment-16077437 ] Guanghao Zhang commented on HBASE-17056: Now if i want run one test, I need "mvn clean install -DskipTests" firstly, then "mvn test -Dtest=TestXXX", right? > Remove checked in PB generated files > - > > Key: HBASE-17056 > URL: https://issues.apache.org/jira/browse/HBASE-17056 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0 >Reporter: Enis Soztutar >Assignee: stack > Fix For: 2.0.0 > > Attachments: > 0002-HBASE-17056-Remove-checked-in-PB-generated-files.patch, > HBASE-17056.master.001.patch, HBASE-17056.master.002.patch, > HBASE-17056.master.003.patch > > > Now that we have the new PB maven plugin, there is no need to have the PB > files checked in to the repo. The reason we did that was to ease up developer > env setup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18329) update links in config guide to point to java 8 references
[
https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077424#comment-16077424
]
Hadoop QA commented on HBASE-18329:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green} 1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 3m
52s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 1m
42s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 2m
35s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 3m
21s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
29m 59s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 2m
10s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 3m 44s{color}
| {color:red} root in the patch failed. {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} 49m 38s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Issue | HBASE-18329 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12876004/HBASE-18329.patch |
| Optional Tests | asflicense javac javadoc unit |
| uname | Linux f1eb15ab1701 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 75d2eca |
| Default Java | 1.8.0_131 |
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7553/artifact/patchprocess/patch-unit-root.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7553/testReport/ |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7553/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> update links in config guide to point to java 8 references
> --
>
> Key: HBASE-18329
> URL: https://issues.apache.org/jira/browse/HBASE-18329
> Project: HBase
> Issue Type: Bug
> Components: documentation
>Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1
>Reporter: Artem Ervits
>Assignee: Artem Ervits
> Fix For: 3.0.0
>
> Attachments: HBASE-18329.patch
>
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14135) HBase Backup/Restore Phase 3: Merge backup images
[
https://issues.apache.org/jira/browse/HBASE-14135?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077412#comment-16077412
]
Vladimir Rodionov commented on HBASE-14135:
---
{quote}
And? What is the intent? To change them? Thanks.
{quote}
Yes. There is a JIRA HBASE-16458.
{quote}
You understand how someone might think 'MR' when they see 'Job'. Do you want to
prevent any confusion?
{quote}
We have had already long discussion about this topic in the past. Should we
start it again?
Originally it was Service, then - Task, now is Job. What do you suggest, stack?
{quote}
And if the client goes away? They query to find running jobs?
{quote}
Job will fail, but next time (run), repair will be started automatically
(mostly cleanup stuff). We have repair tool, just in case if "client goes away"
or some other disaster happens.
> HBase Backup/Restore Phase 3: Merge backup images
> -
>
> Key: HBASE-14135
> URL: https://issues.apache.org/jira/browse/HBASE-14135
> Project: HBase
> Issue Type: New Feature
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Labels: backup
> Fix For: HBASE-7912
>
> Attachments: HBASE-14135-v1.patch, HBASE-14135-v3.patch
>
>
> User can merge incremental backup images into single incremental backup image.
> # Merge supports only incremental images
> # Merge supports only images for the same backup destinations
> Command:
> {code}
> hbase backup merge image1,image2,..imageK
> {code}
> Example:
> {code}
> hbase backup merge backup_143126764557,backup_143126764456
> {code}
> When operation is complete, only the most recent backup image will be kept
> (in above example - backup_143126764557) as a merged backup image, all other
> images will be deleted from both: file system and backup system tables,
> corresponding backup manifest for the merged backup image will be updated to
> remove dependencies from deleted images. Merged backup image will contains
> all the data from original image and from deleted images.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Reopened] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov reopened HBASE-16458:
---
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: backup
> Fix For: 2.0.0
>
> Attachments: 16458.HBASE-7912.v3.txt, 16458.HBASE-7912.v4.txt,
> 16458.HBASE-7912.v5.txt, 16458.v1.txt, 16458.v2.txt, 16458.v3.txt
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Running
> org.apache.hadoop.hbase.backup.TestBackupShowHistoryFromBackupDestination
> Tests run: 3, Failures: 0, Errors: 0,
[jira] [Updated] (HBASE-16458) Shorten backup / restore test execution time
[
https://issues.apache.org/jira/browse/HBASE-16458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-16458:
--
Fix Version/s: (was: HBASE-7912)
2.0.0
> Shorten backup / restore test execution time
>
>
> Key: HBASE-16458
> URL: https://issues.apache.org/jira/browse/HBASE-16458
> Project: HBase
> Issue Type: Test
>Reporter: Ted Yu
>Assignee: Ted Yu
> Labels: backup
> Fix For: 2.0.0
>
> Attachments: 16458.HBASE-7912.v3.txt, 16458.HBASE-7912.v4.txt,
> 16458.HBASE-7912.v5.txt, 16458.v1.txt, 16458.v2.txt, 16458.v3.txt
>
>
> Below was timing information for all the backup / restore tests (today's
> result):
> {code}
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 576.273 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackup
> Running org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 124.67 sec -
> in org.apache.hadoop.hbase.backup.TestBackupBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 102.34 sec -
> in org.apache.hadoop.hbase.backup.TestBackupStatusProgress
> Running org.apache.hadoop.hbase.backup.TestBackupAdmin
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 490.251 sec -
> in org.apache.hadoop.hbase.backup.TestBackupAdmin
> Running org.apache.hadoop.hbase.backup.TestHFileArchiving
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.323 sec -
> in org.apache.hadoop.hbase.backup.TestHFileArchiving
> Running org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.492 sec -
> in org.apache.hadoop.hbase.backup.TestSystemTableSnapshot
> Running org.apache.hadoop.hbase.backup.TestBackupDescribe
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 93.758 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDescribe
> Running org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 109.187 sec -
> in org.apache.hadoop.hbase.backup.TestBackupLogCleaner
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 330.539 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupNoDataLoss
> Running org.apache.hadoop.hbase.backup.TestRemoteBackup
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 84.371 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteBackup
> Running org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.893 sec -
> in org.apache.hadoop.hbase.backup.TestBackupSystemTable
> Running org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 120.779 sec -
> in org.apache.hadoop.hbase.backup.TestRestoreBoundaryTests
> Running org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 117.815 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSetRestoreSet
> Running org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 136.517 sec -
> in org.apache.hadoop.hbase.backup.TestBackupShowHistory
> Running org.apache.hadoop.hbase.backup.TestRemoteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.799 sec -
> in org.apache.hadoop.hbase.backup.TestRemoteRestore
> Running org.apache.hadoop.hbase.backup.TestFullRestore
> Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 317.711 sec
> - in org.apache.hadoop.hbase.backup.TestFullRestore
> Running org.apache.hadoop.hbase.backup.TestFullBackupSet
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 87.045 sec -
> in org.apache.hadoop.hbase.backup.TestFullBackupSet
> Running org.apache.hadoop.hbase.backup.TestBackupDelete
> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.214 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDelete
> Running org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 77.631 sec -
> in org.apache.hadoop.hbase.backup.TestBackupDeleteRestore
> Running org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 190.358 sec -
> in org.apache.hadoop.hbase.backup.TestIncrementalBackupDeleteTable
> Running
>
[jira] [Assigned] (HBASE-12349) Add Maven build support module for a custom version of error-prone
[ https://issues.apache.org/jira/browse/HBASE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob reassigned HBASE-12349: - Assignee: Mike Drob > Add Maven build support module for a custom version of error-prone > -- > > Key: HBASE-12349 > URL: https://issues.apache.org/jira/browse/HBASE-12349 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell >Assignee: Mike Drob > Fix For: 2.0.0 > > Attachments: HBASE-12349.patch > > > Add a new Maven build support module that builds and publishes a custom > error-prone artifact for use by the rest of the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077364#comment-16077364 ] Ted Yu commented on HBASE-18329: lgtm > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Ervits updated HBASE-18329: - Status: Patch Available (was: Open) > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 2.0.0-alpha-1, 1.1.11, 1.2.6, 1.3.1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18329) update links in config guide to point to java 8 references
[ https://issues.apache.org/jira/browse/HBASE-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Ervits updated HBASE-18329: - Attachment: HBASE-18329.patch > update links in config guide to point to java 8 references > -- > > Key: HBASE-18329 > URL: https://issues.apache.org/jira/browse/HBASE-18329 > Project: HBase > Issue Type: Bug > Components: documentation >Affects Versions: 1.3.1, 1.2.6, 1.1.11, 2.0.0-alpha-1 >Reporter: Artem Ervits >Assignee: Artem Ervits > Fix For: 3.0.0 > > Attachments: HBASE-18329.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Attachment: 0001-HBASE-14070-Undoing-the-use-of-master-s-timestamp-fo.patch > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: > 0001-HBASE-14070-Undoing-the-use-of-master-s-timestamp-fo.patch, > HBASE-18328.HBASE-14070.HLC.001.patch > > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Status: Patch Available (was: Open) > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18328.HBASE-14070.HLC.001.patch > > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Status: Open (was: Patch Available) > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18328.HBASE-14070.HLC.001.patch > > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18329) update links in config guide to point to java 8 references
Artem Ervits created HBASE-18329: Summary: update links in config guide to point to java 8 references Key: HBASE-18329 URL: https://issues.apache.org/jira/browse/HBASE-18329 Project: HBase Issue Type: Bug Components: documentation Affects Versions: 2.0.0-alpha-1, 1.1.11, 1.2.6, 1.3.1 Reporter: Artem Ervits Assignee: Artem Ervits Fix For: 3.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077346#comment-16077346
]
Sean Busbey commented on HBASE-18327:
-
applying the patch locally works fine. I've asked for help on dev@yetus about
what's failing.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16415) Replication in different namespace
[
https://issues.apache.org/jira/browse/HBASE-16415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077340#comment-16077340
]
Hadoop QA commented on HBASE-16415:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
29s{color} | {color:blue} Docker mode activated. {color} |
| {color:green} 1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green} 1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green} 1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 3 new or modified test
files. {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 7m
3s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} compile {color} | {color:green} 1m
23s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 1m
26s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 6m
13s{color} | {color:red} hbase-server in master has 10 extant Findbugs
warnings. {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 0m
55s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} compile {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} javac {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 1m
30s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 0m
28s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
83m 24s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 11m
27s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 2m
4s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}266m 10s{color}
| {color:red} hbase-server in the patch failed. {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}387m 27s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests |
hadoop.hbase.replication.multiwal.TestReplicationEndpointWithMultipleWAL |
| | hadoop.hbase.snapshot.TestMobRestoreFlushSnapshotFromClient |
| | hadoop.hbase.regionserver.TestPerColumnFamilyFlush |
| | hadoop.hbase.security.access.TestCoprocessorWhitelistMasterObserver |
| | hadoop.hbase.master.procedure.TestProcedureAdmin |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:757bf37 |
| JIRA Issue | HBASE-16415 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875952/HBASE-16415.patch |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 85f86c18e3e0 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 75d2eca |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| findbugs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7542/artifact/patchprocess/branch-findbugs-hbase-server-warnings.html
|
| unit |
https://builds.apache.org/job/PreCommit-HBASE-Build/7542/artifact/patchprocess/patch-unit-hbase-server.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/7542/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Attachment: HBASE-18328.HBASE-14070.HLC.001.patch > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > Attachments: HBASE-18328.HBASE-14070.HLC.001.patch > > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17908) Upgrade guava
[
https://issues.apache.org/jira/browse/HBASE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077327#comment-16077327
]
Hadoop QA commented on HBASE-17908:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
34s{color} | {color:blue} Docker mode activated. {color} |
| {color:green} 1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green} 1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green} 1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 210 new or modified
test files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
38s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 4m
48s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
45s{color} | {color:red} root in master failed. {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 7m
27s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 5m
43s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util hbase-assembly . {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
33s{color} | {color:red} hbase-common in master has 2 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
49s{color} | {color:red} hbase-client in master has 4 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 3m
0s{color} | {color:red} hbase-server in master has 10 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
35s{color} | {color:red} hbase-rest in master has 3 extant Findbugs warnings.
{color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 6m
29s{color} | {color:green} master passed {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} 9m
22s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
34s{color} | {color:red} root in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 34s{color}
| {color:red} root in the patch failed. {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 6m
38s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 5m
31s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green} 1{color} | {color:green} xml {color} | {color:green} 0m
25s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
30m 12s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util hbase-assembly . {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
39s{color} | {color:green} hbase-common generated 0 new 0 unchanged - 2 fixed
= 0 total (was 2) {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
23s{color} | {color:green} hbase-metrics-api in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
28s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
23s{color} | {color:green} hbase-hadoop-compat in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 0m
23s{color} | {color:green} hbase-metrics in the patch passed. {color} |
| {color:green} 1{color} | {color:green} findbugs
[jira] [Commented] (HBASE-18324) [hbase-thirdparty] Tooling to prevent commits that mistakenly make use of unshaded protobuf/guava/etc.
[ https://issues.apache.org/jira/browse/HBASE-18324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077306#comment-16077306 ] Mike Drob commented on HBASE-18324: --- bq. we should be able to reuse the same tooling we use to check for use of the hadoop annotations. oh, that's easy, that's a grep in hbase-personality.sh Do we have a list of which package/imports to ban? > [hbase-thirdparty] Tooling to prevent commits that mistakenly make use of > unshaded protobuf/guava/etc. > -- > > Key: HBASE-18324 > URL: https://issues.apache.org/jira/browse/HBASE-18324 > Project: HBase > Issue Type: Bug >Reporter: stack > > Chatting w/ [~mdrob], he brought up the question of what if a dev makes use > of unshaded protobuf or guava? Afterall, the old jars (pb2.5 and hadoops > guava12.0 or whatever) are still on the CLASSPATH because upstream depends on > them. > We could add a check as part of prebuild. It would complain if use of > com.google instead of org.apache.hadoop.hbase.shaded.com.google. But even > then, there are cases where com.google is legit (coprocessor endpoints) so it > would have to let these pass. > TODO. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12349) Add Maven build support module for a custom version of error-prone
[ https://issues.apache.org/jira/browse/HBASE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077298#comment-16077298 ] Andrew Purtell commented on HBASE-12349: I don't think we want to do this by default but can turn on under the release profile for RCs and nightlies. > Add Maven build support module for a custom version of error-prone > -- > > Key: HBASE-12349 > URL: https://issues.apache.org/jira/browse/HBASE-12349 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell > Fix For: 2.0.0 > > Attachments: HBASE-12349.patch > > > Add a new Maven build support module that builds and publishes a custom > error-prone artifact for use by the rest of the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12349) Add Maven build support module for a custom version of error-prone
[ https://issues.apache.org/jira/browse/HBASE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-12349: -- Attachment: HBASE-12349.patch Progress update: have some ugly hacks on this. I know I'm missing license headers, and have hard-coded plugin version in maven, but I'm almost to a place where this works. Big issue now is that compiling protoc goes from ~15s to ~5m which I consider a deal breaker. Maybe not to commit, but to turning error-prone on by default. I started to do a few fixups on the code based on errors that were getting reported, but stopped when the protoc issue made the process take way too long. [~apurtell] - care to take a look at what's here so far and provide thoughts? > Add Maven build support module for a custom version of error-prone > -- > > Key: HBASE-12349 > URL: https://issues.apache.org/jira/browse/HBASE-12349 > Project: HBase > Issue Type: Sub-task >Reporter: Andrew Purtell > Fix For: 2.0.0 > > Attachments: HBASE-12349.patch > > > Add a new Maven build support module that builds and publishes a custom > error-prone artifact for use by the rest of the build. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17908) Upgrade guava
[ https://issues.apache.org/jira/browse/HBASE-17908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-17908: -- Attachment: 0001-HBASE-17908-Upgrade-guava.022.patch Rebase. The submit-patch tool is making non-patches for me > Upgrade guava > - > > Key: HBASE-17908 > URL: https://issues.apache.org/jira/browse/HBASE-17908 > Project: HBase > Issue Type: Sub-task > Components: dependencies >Reporter: Balazs Meszaros >Assignee: stack >Priority: Critical > Fix For: 2.0.0 > > Attachments: 0001-HBASE-17908-Upgrade-guava.022.patch, > HBASE-17908.master.001.patch, HBASE-17908.master.002.patch, > HBASE-17908.master.003.patch, HBASE-17908.master.004.patch, > HBASE-17908.master.005.patch, HBASE-17908.master.006.patch, > HBASE-17908.master.007.patch, HBASE-17908.master.008.patch, > HBASE-17908.master.009.patch, HBASE-17908.master.010.patch, > HBASE-17908.master.011.patch, HBASE-17908.master.012.patch, > HBASE-17908.master.013.patch, HBASE-17908.master.013.patch, > HBASE-17908.master.014.patch, HBASE-17908.master.015.patch, > HBASE-17908.master.015.patch, HBASE-17908.master.016.patch, > HBASE-17908.master.017.patch, HBASE-17908.master.018.patch, > HBASE-17908.master.019.patch, HBASE-17908.master.020.patch, > HBASE-17908.master.021.patch, HBASE-17908.master.021.patch > > > Currently we are using guava 12.0.1, but the latest version is 21.0. > Upgrading guava is always a hassle because it is not always backward > compatible with itself. > Currently I think there are to approaches: > 1. Upgrade guava to the newest version (21.0) and shade it. > 2. Upgrade guava to a version which does not break or builds (15.0). > If we can update it, some dependencies should be removed: > commons-collections, commons-codec, ... -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077280#comment-16077280 ] stack commented on HBASE-10240: --- Thanks [~enis] Would be cool to purge this stuff if we can. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077262#comment-16077262
]
Hadoop QA commented on HBASE-18327:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 3s{color}
| {color:red} HBASE-18327 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875989/HBASE-18327.1.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7551/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18078) [C++] Harden RPC by handling various communication abnormalities
[ https://issues.apache.org/jira/browse/HBASE-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077259#comment-16077259 ] Xiaobing Zhou edited comment on HBASE-18078 at 7/6/17 10:05 PM: Posted v3. # fixed rebase conflicts # added RPC test server skeleton [~enis] you are right, we are not going change behaviors of connection establishment. The initial attempt of AsyncConnect is to satisfy connection pool or pass the existing unit tests. I will get back by removing the async later on. Thanks. was (Author: xiaobingo): Posted v3. # fixed rebase conflicts # add RPC test server skeleton [~enis] you are right, we are not going change behaviors of connection establishment. The initial attempt of AsyncConnect is to satisfy connection pool or pass the existing unit tests. I will get back by removing the async later on. Thanks. > [C++] Harden RPC by handling various communication abnormalities > > > Key: HBASE-18078 > URL: https://issues.apache.org/jira/browse/HBASE-18078 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-18078.000.patch, HBASE-18078.001.patch, > HBASE-18078.002.patch, HBASE-18078.003.patch > > > RPC layer should handle various communication abnormalities (e.g. connection > timeout, server aborted connection, and so on). Ideally, the corresponding > exceptions should be raised and propagated through handlers of pipeline in > client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18078) [C++] Harden RPC by handling various communication abnormalities
[ https://issues.apache.org/jira/browse/HBASE-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077259#comment-16077259 ] Xiaobing Zhou commented on HBASE-18078: --- Posted v3. # fixed rebase conflicts # add RPC test server skeleton # [~enis] you are right, we are not going change behaviors of connection establishment. The initial attempt of AsyncConnect is to satisfy connection pool or pass the existing unit tests. I will get back by removing the async later on. Thanks. > [C++] Harden RPC by handling various communication abnormalities > > > Key: HBASE-18078 > URL: https://issues.apache.org/jira/browse/HBASE-18078 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-18078.000.patch, HBASE-18078.001.patch, > HBASE-18078.002.patch, HBASE-18078.003.patch > > > RPC layer should handle various communication abnormalities (e.g. connection > timeout, server aborted connection, and so on). Ideally, the corresponding > exceptions should be raised and propagated through handlers of pipeline in > client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18327:
Attachment: HBASE-18327.1.patch
new patch created with git diff instead of format-patch
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch, HBASE-18327.1.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18078) [C++] Harden RPC by handling various communication abnormalities
[ https://issues.apache.org/jira/browse/HBASE-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077259#comment-16077259 ] Xiaobing Zhou edited comment on HBASE-18078 at 7/6/17 10:03 PM: Posted v3. # fixed rebase conflicts # add RPC test server skeleton [~enis] you are right, we are not going change behaviors of connection establishment. The initial attempt of AsyncConnect is to satisfy connection pool or pass the existing unit tests. I will get back by removing the async later on. Thanks. was (Author: xiaobingo): Posted v3. # fixed rebase conflicts # add RPC test server skeleton # [~enis] you are right, we are not going change behaviors of connection establishment. The initial attempt of AsyncConnect is to satisfy connection pool or pass the existing unit tests. I will get back by removing the async later on. Thanks. > [C++] Harden RPC by handling various communication abnormalities > > > Key: HBASE-18078 > URL: https://issues.apache.org/jira/browse/HBASE-18078 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-18078.000.patch, HBASE-18078.001.patch, > HBASE-18078.002.patch, HBASE-18078.003.patch > > > RPC layer should handle various communication abnormalities (e.g. connection > timeout, server aborted connection, and so on). Ideally, the corresponding > exceptions should be raised and propagated through handlers of pipeline in > client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077256#comment-16077256
]
Hadoop QA commented on HBASE-18327:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-18327 does not apply to master. Rebase required? Wrong
Branch? See
https://yetus.apache.org/documentation/in-progress/precommit-patchnames for
help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875972/HBASE-18327.0.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7550/console |
| Powered by | Apache Yetus 0.5.0-SNAPSHOT http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18078) [C++] Harden RPC by handling various communication abnormalities
[ https://issues.apache.org/jira/browse/HBASE-18078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaobing Zhou updated HBASE-18078: -- Attachment: HBASE-18078.003.patch > [C++] Harden RPC by handling various communication abnormalities > > > Key: HBASE-18078 > URL: https://issues.apache.org/jira/browse/HBASE-18078 > Project: HBase > Issue Type: Sub-task >Reporter: Xiaobing Zhou >Assignee: Xiaobing Zhou > Attachments: HBASE-18078.000.patch, HBASE-18078.001.patch, > HBASE-18078.002.patch, HBASE-18078.003.patch > > > RPC layer should handle various communication abnormalities (e.g. connection > timeout, server aborted connection, and so on). Ideally, the corresponding > exceptions should be raised and propagated through handlers of pipeline in > client. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077248#comment-16077248
]
Hadoop QA commented on HBASE-18327:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 3s{color}
| {color:red} HBASE-18327 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875972/HBASE-18327.0.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7549/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077247#comment-16077247
]
Hadoop QA commented on HBASE-18327:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
1s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 3s{color}
| {color:red} HBASE-18327 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875972/HBASE-18327.0.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7548/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[
https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077244#comment-16077244
]
Enis Soztutar commented on HBASE-10240:
---
I was doing some digging. Findings so far:
9e249881ef6a49879511be24e11d717738085dd5 (HBASE-7224) added this to the javadoc
for HbaseObjectWritableFor96Migration
{code}
* @deprecated This class is needed migrating TablePermissions written with
* Writables. It is needed to read old permissions written pre-0.96. This
* class is to be removed after HBase 0.96 ships since then all permissions
* will have been migrated and written with protobufs.
{code}
However, when reading the code {{TablePermissions}}, which extends
{{Permission}} which is still {{Writable}} and never made PB I guess. There is
also a couple of other Writables like AuthenticationKey.
It seems (from my reading of the code) that we are using PB's in the RPC, but
we are reading and writing these objects from the ACL table or ZK using
Writables. However, I think neither of these depends on
HbaseObjectWritableFor96Migration per se, so the patch maybe good as it is.
> Remove 0.94->0.96 migration code
>
>
> Key: HBASE-10240
> URL: https://issues.apache.org/jira/browse/HBASE-10240
> Project: HBase
> Issue Type: Improvement
>Reporter: Andrew Purtell
>Assignee: Peter Somogyi
>Priority: Critical
> Fix For: 3.0.0, 2.0.0-alpha-2
>
> Attachments: HBASE-10240.master.001.patch,
> HBASE-10240.master.001.patch
>
>
> Remove the objects and code only needed for supporting migration to 0.96 from
> 0.94.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-14070) Hybrid Logical Clocks for HBase
[ https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077216#comment-16077216 ] Amit Patel commented on HBASE-14070: [Plan for Hybrid Logical Clocks|http://apache-hbase.679495.n3.nabble.com/Plan-for-Hybrid-Logical-Clocks-td4088705.html] covers the plan of moving the current HLC work upstream and how additional functionality would be introduced. > Hybrid Logical Clocks for HBase > --- > > Key: HBASE-14070 > URL: https://issues.apache.org/jira/browse/HBASE-14070 > Project: HBase > Issue Type: New Feature >Reporter: Enis Soztutar >Assignee: Amit Patel > Attachments: HBASE-14070.master.001.patch, > HybridLogicalClocksforHBaseandPhoenix.docx, > HybridLogicalClocksforHBaseandPhoenix.pdf > > > HBase and Phoenix uses systems physical clock (PT) to give timestamps to > events (read and writes). This works mostly when the system clock is strictly > monotonically increasing and there is no cross-dependency between servers > clocks. However we know that leap seconds, general clock skew and clock drift > are in fact real. > This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of > hybrid physical clock + a logical clock. HLC is best of both worlds where it > keeps causality relationship similar to logical clocks, but still is > compatible with NTP based physical system clock. HLC can be represented in > 64bits. > A design document is attached and also can be found here: > https://docs.google.com/document/d/1LL2GAodiYi0waBz5ODGL4LDT4e_bXy8P9h6kWC05Bhw/edit# -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Description: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the [HBASE-14070.HLC](https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC) branch. Credit for this work all goes to our [~saitejar]. was: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the [HBASE-14070.HLC] branch. Credit for this work all goes to our [~saitejar]. > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC](https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC) > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Description: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] branch. Credit for this work all goes to our [~saitejar]. was: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the [HBASE-14070.HLC](https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC) branch. Credit for this work all goes to our [~saitejar]. > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the > [HBASE-14070.HLC|https://git-wip-us.apache.org/repos/asf?p=hbase.git;a=shortlog;h=refs/heads/HBASE-14070.HLC] > branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Description: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the [HBASE-14070.HLC] branch. Credit for this work all goes to our [~saitejar]. was: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the "HBASE-14070.HLC" branch. Credit for this work all goes to our [~saitejar]. > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the [HBASE-14070.HLC] branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18328) Undoing using the master's timestamp for meta updates
[ https://issues.apache.org/jira/browse/HBASE-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18328: --- Description: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the "HBASE-14070.HLC" branch. Credit for this work all goes to our [~saitejar]. was: After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the HBASE-14070.HLC branch. Credit for this work all goes to our [~saitejar]. > Undoing using the master's timestamp for meta updates > - > > Key: HBASE-18328 > URL: https://issues.apache.org/jira/browse/HBASE-18328 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel >Priority: Minor > > After introducing [the Core HLC > framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step > is to remove all instances where the timestamp is explicitly set for meta > updates. Most of these changes take place in MetaTableAccessor. The patch for > this task will be going against the "HBASE-14070.HLC" branch. > Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18328) Undoing using the master's timestamp for meta updates
Amit Patel created HBASE-18328: -- Summary: Undoing using the master's timestamp for meta updates Key: HBASE-18328 URL: https://issues.apache.org/jira/browse/HBASE-18328 Project: HBase Issue Type: Sub-task Reporter: Amit Patel Assignee: Amit Patel Priority: Minor After introducing [the Core HLC framework|https://issues.apache.org/jira/browse/HBASE-18305], the next step is to remove all instances where the timestamp is explicitly set for meta updates. Most of these changes take place in MetaTableAccessor. The patch for this task will be going against the HBASE-14070.HLC branch. Credit for this work all goes to our [~saitejar]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077175#comment-16077175 ] stack commented on HBASE-10240: --- Ok [~enis] Then I suppose migration tool will need at least an instance of HbaseObjectWritableFor96Migration. You know if this discussed elsewhere [~enis] ? (I can look myself.. but in case you remember...) Ok [~psomogyi]. We can't go further here till we figure out the auto-migration of ACL in branch-1. Thanks for the patch to get us this far. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[
https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077173#comment-16077173
]
Hadoop QA commented on HBASE-10240:
---
| (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: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:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
15s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green} 1{color} | {color:green} mvninstall {color} | {color:green} 3m
20s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 0m
39s{color} | {color:green} master passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m
32s{color} | {color:red} hbase-common in master has 2 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m
36s{color} | {color:red} hbase-server in master has 10 extant Findbugs
warnings. {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} master passed {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} 1m
1s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} compile {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} javac {color} | {color:green} 0m
54s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} checkstyle {color} | {color:green} 0m
39s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green} 1{color} | {color:green} hadoopcheck {color} | {color:green}
29m 8s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha3. {color} |
| {color:green} 1{color} | {color:green} findbugs {color} | {color:green} 3m
45s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} javadoc {color} | {color:green} 0m
45s{color} | {color:green} the patch passed {color} |
| {color:green} 1{color} | {color:green} unit {color} | {color:green} 2m
11s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green} 1{color} | {color:green} unit {color} | {color:green}113m
15s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green} 1{color} | {color:green} asflicense {color} | {color:green} 0m
32s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}162m 56s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:757bf37 |
| JIRA Issue | HBASE-10240 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875961/HBASE-10240.master.001.patch
|
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 64886360651a 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 75d2eca |
| Default Java | 1.8.0_131 |
| findbugs | v3.1.0-RC3 |
| findbugs |
https://builds.apache.org/job/PreCommit-HBASE-Build/7546/artifact/patchprocess/branch-findbugs-hbase-common-warnings.html
|
| findbugs |
[jira] [Commented] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077168#comment-16077168 ] Yi Liang commented on HBASE-18229: -- try it on local, no this OutOfMemoryError. Maybe some env problems? > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang >Priority: Critical > Fix For: 2.0.0-alpha-2 > > Attachments: HBase-18229-master-v1.patch, > hbase-18229-master-v2.patch, HBASE-18229-master-v3.patch, > hbase-18229-master-v4.patch, hbase-18229-master-v5.patch, > hbase-18229-master-v6.patch, hbase-18229-master-v6.patch > > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer ask Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18305) Initial patch (Core HLC) for public branch
[ https://issues.apache.org/jira/browse/HBASE-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack resolved HBASE-18305. --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: HBASE-14070 Release Note: Adds Core HLC framework (i.e., Clock, Timestamp API) and tests. Practically all of this work has been done by our [~saitejar]. This patch in particular intentionally does not include: * undoing using the master's timestamp for meta updates, * enabling HLC for meta * updating the clock for events like recovery, replication, region open/close. Pushed to HBASE-10470.HLC branch. Thanks for the patch [~amit.patel]! > Initial patch (Core HLC) for public branch > -- > > Key: HBASE-18305 > URL: https://issues.apache.org/jira/browse/HBASE-18305 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel > Fix For: HBASE-14070 > > Attachments: 0001-HBASE-14070-Core-HLC-revision-1.patch, > HBASE-18305.HBASE-14070.HLC.001.patch, HBASE-18305.master.001.patch, > HBASE-18305.master.002.patch, HBASE-18305.master.003.patch > > > Used for tracking the status of the initial patch for HLC. Core HLC refers to > the addition of the HLC framework (i.e., Clock, Timestamp API), integration > of said framework with the codebase, and changes to tests. Practically all of > this work has been done by our [~saitejar]. > This patch in particular intentionally does not include: > * undoing using the master's timestamp for meta updates, > * enabling HLC for meta > * updating the clock for events like recovery, replication, region > open/close. > These changes will be introduced soon in smaller followup commits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077165#comment-16077165 ] Enis Soztutar commented on HBASE-10240: --- Thanks Stack. I think the problem is that even if you have a 1.3 cluster, if you have upgraded from 0.94 before, you are left with Writable data since we do not auto-migrate. And there is no migration code to re-write the ACL table as of now. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18305) Initial patch (Core HLC) for public branch
[ https://issues.apache.org/jira/browse/HBASE-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18305: --- Attachment: 0001-HBASE-14070-Core-HLC-revision-1.patch > Initial patch (Core HLC) for public branch > -- > > Key: HBASE-18305 > URL: https://issues.apache.org/jira/browse/HBASE-18305 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel > Attachments: 0001-HBASE-14070-Core-HLC-revision-1.patch, > HBASE-18305.HBASE-14070.HLC.001.patch, HBASE-18305.master.001.patch, > HBASE-18305.master.002.patch, HBASE-18305.master.003.patch > > > Used for tracking the status of the initial patch for HLC. Core HLC refers to > the addition of the HLC framework (i.e., Clock, Timestamp API), integration > of said framework with the codebase, and changes to tests. Practically all of > this work has been done by our [~saitejar]. > This patch in particular intentionally does not include: > * undoing using the master's timestamp for meta updates, > * enabling HLC for meta > * updating the clock for events like recovery, replication, region > open/close. > These changes will be introduced soon in smaller followup commits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18305) Initial patch (Core HLC) for public branch
[ https://issues.apache.org/jira/browse/HBASE-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077152#comment-16077152 ] stack commented on HBASE-18305: --- 1 Let me commit to the HBASE-18304.HLC branch. > Initial patch (Core HLC) for public branch > -- > > Key: HBASE-18305 > URL: https://issues.apache.org/jira/browse/HBASE-18305 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel > Attachments: HBASE-18305.HBASE-14070.HLC.001.patch, > HBASE-18305.master.001.patch, HBASE-18305.master.002.patch, > HBASE-18305.master.003.patch > > > Used for tracking the status of the initial patch for HLC. Core HLC refers to > the addition of the HLC framework (i.e., Clock, Timestamp API), integration > of said framework with the codebase, and changes to tests. Practically all of > this work has been done by our [~saitejar]. > This patch in particular intentionally does not include: > * undoing using the master's timestamp for meta updates, > * enabling HLC for meta > * updating the clock for events like recovery, replication, region > open/close. > These changes will be introduced soon in smaller followup commits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077139#comment-16077139
]
Hadoop QA commented on HBASE-18327:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 4s{color}
| {color:red} HBASE-18327 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18327 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12875972/HBASE-18327.0.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/7547/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-13631) Migration from 0.94 to 2.0.0
[ https://issues.apache.org/jira/browse/HBASE-13631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077135#comment-16077135 ] stack commented on HBASE-13631: --- Another item mentioned by [~enis] over in HBASE-10240 is that ACLs may need migrating before can go to 2.0. If we don't already (I don't know), then we need a tool to do migration ahead of the move to 2.0 (or to do it in-place as part of startup). > Migration from 0.94 to 2.0.0 > > > Key: HBASE-13631 > URL: https://issues.apache.org/jira/browse/HBASE-13631 > Project: HBase > Issue Type: Sub-task > Components: migration >Reporter: Anoop Sam John >Priority: Blocker > Fix For: 2.0.0 > > > We have HFile V2 (minor version-2) only in 0.94 and 2.0 needs HFile V3 with > minor version 3 atleast. We can test and document clearly the path of upgrade > from 94.x to 2.0.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077136#comment-16077136 ] stack commented on HBASE-10240: --- I added note over on HBASE-13631 in meantime. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18305) Initial patch (Core HLC) for public branch
[ https://issues.apache.org/jira/browse/HBASE-18305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Patel updated HBASE-18305: --- Attachment: HBASE-18305.master.003.patch > Initial patch (Core HLC) for public branch > -- > > Key: HBASE-18305 > URL: https://issues.apache.org/jira/browse/HBASE-18305 > Project: HBase > Issue Type: Sub-task >Reporter: Amit Patel >Assignee: Amit Patel > Attachments: HBASE-18305.HBASE-14070.HLC.001.patch, > HBASE-18305.master.001.patch, HBASE-18305.master.002.patch, > HBASE-18305.master.003.patch > > > Used for tracking the status of the initial patch for HLC. Core HLC refers to > the addition of the HLC framework (i.e., Clock, Timestamp API), integration > of said framework with the codebase, and changes to tests. Practically all of > this work has been done by our [~saitejar]. > This patch in particular intentionally does not include: > * undoing using the master's timestamp for meta updates, > * enabling HLC for meta > * updating the clock for events like recovery, replication, region > open/close. > These changes will be introduced soon in smaller followup commits. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077130#comment-16077130 ] stack commented on HBASE-10240: --- Or, thinking on it [~enis], we should just not support going from 0.94 to 2.0. I think this purge is legit in 2.0. Let us know if you think different. For the ACL issue, can I add to our migration guide how to address old serializations (do you know)? I'll add note in meantime > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18327:
Attachment: HBASE-18327.0.patch
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18327:
Status: Patch Available (was: Open)
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
> Attachments: HBASE-18327.0.patch
>
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
[
https://issues.apache.org/jira/browse/HBASE-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reassigned HBASE-18327:
---
Assignee: Sean Busbey
> redo test-patch personality 'hadoopcheck' to better account for feature
> branches
>
>
> Key: HBASE-18327
> URL: https://issues.apache.org/jira/browse/HBASE-18327
> Project: HBase
> Issue Type: Improvement
> Components: build, test
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Minor
>
> right now our 'which hadoop checks do we need' check looks like this:
> {code}
> if [[ "${PATCH_BRANCH}" = "master" ]]; then
> hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
> elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
> hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
> else
> hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
> hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
> fi
> {code}
> the check is basically "if master do this, if like branch-2 do that,
> otherwise behave like branch-1".
> we often have feature branches that thus end up being treated like branch-1,
> even though those branches should all be based off of master. (since we
> follow a master-first development approach.)
> we should redo this check so it's "if branch-1 do this, if branch-2 do that,
> otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18327) redo test-patch personality 'hadoopcheck' to better account for feature branches
Sean Busbey created HBASE-18327:
---
Summary: redo test-patch personality 'hadoopcheck' to better
account for feature branches
Key: HBASE-18327
URL: https://issues.apache.org/jira/browse/HBASE-18327
Project: HBase
Issue Type: Improvement
Components: build, test
Reporter: Sean Busbey
Priority: Minor
right now our 'which hadoop checks do we need' check looks like this:
{code}
if [[ "${PATCH_BRANCH}" = "master" ]]; then
hbase_hadoop2_versions=${HBASE_MASTER_HADOOP2_VERSIONS}
hbase_hadoop3_versions=${HBASE_MASTER_HADOOP3_VERSIONS}
elif [[ ${PATCH_BRANCH} = branch-2* ]]; then
hbase_hadoop2_versions=${HBASE_BRANCH2_HADOOP2_VERSIONS}
hbase_hadoop3_versions=${HBASE_BRANCH2_HADOOP3_VERSIONS}
else
hbase_hadoop2_versions=${HBASE_HADOOP2_VERSIONS}
hbase_hadoop3_versions=${HBASE_HADOOP3_VERSIONS}
fi
{code}
the check is basically "if master do this, if like branch-2 do that, otherwise
behave like branch-1".
we often have feature branches that thus end up being treated like branch-1,
even though those branches should all be based off of master. (since we follow
a master-first development approach.)
we should redo this check so it's "if branch-1 do this, if branch-2 do that,
otherwise behave like master"
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18229) create new Async Split API to embrace AM v2
[ https://issues.apache.org/jira/browse/HBASE-18229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077108#comment-16077108 ] stack commented on HBASE-18229: --- Weird... we are OutOfMemoryError ... now (not because of this patch... seeing it in other places too). > create new Async Split API to embrace AM v2 > --- > > Key: HBASE-18229 > URL: https://issues.apache.org/jira/browse/HBASE-18229 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Reporter: Yi Liang >Assignee: Yi Liang >Priority: Critical > Fix For: 2.0.0-alpha-2 > > Attachments: HBase-18229-master-v1.patch, > hbase-18229-master-v2.patch, HBASE-18229-master-v3.patch, > hbase-18229-master-v4.patch, hbase-18229-master-v5.patch, > hbase-18229-master-v6.patch, hbase-18229-master-v6.patch > > > See HBASE-18105 for related information, this jira will change the logic of > Path 1 in splitProcedure, the execution path will be: > *HBaseAdmin.splitRegionAsync -> MasterKeepAliveConnection.splitRegion -> > MasterRpcServices.splitRegion -> HMaster.splitRegion-> > AssignmentManager.submitProcedure* > Master Will no longer ask Rs and then Rs turn around to ask master to do the > split operation. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077106#comment-16077106 ] stack commented on HBASE-10240: --- Thanks [~enis] for the helpful input. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-10240) Remove 0.94->0.96 migration code
[ https://issues.apache.org/jira/browse/HBASE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16077093#comment-16077093 ] Enis Soztutar commented on HBASE-10240: --- I remember that the ACLs in the ACL table are not auto-migrated to the PB format (last time I checked was long time ago though). If that is the case, if any cluster has those left in the ACL table because the cluster is going through 0.94 -> 0.98 -> 1.x -> 2.0 code bases, than the ACLs will fail. Can we please check that. > Remove 0.94->0.96 migration code > > > Key: HBASE-10240 > URL: https://issues.apache.org/jira/browse/HBASE-10240 > Project: HBase > Issue Type: Improvement >Reporter: Andrew Purtell >Assignee: Peter Somogyi >Priority: Critical > Fix For: 3.0.0, 2.0.0-alpha-2 > > Attachments: HBASE-10240.master.001.patch, > HBASE-10240.master.001.patch > > > Remove the objects and code only needed for supporting migration to 0.96 from > 0.94. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18102) [SHELL] Purge commands that allow by-pass of Master; e.g. close of a region sent to regionserver explicitly
[ https://issues.apache.org/jira/browse/HBASE-18102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe reassigned HBASE-18102: Assignee: Umesh Agashe > [SHELL] Purge commands that allow by-pass of Master; e.g. close of a region > sent to regionserver explicitly > --- > > Key: HBASE-18102 > URL: https://issues.apache.org/jira/browse/HBASE-18102 > Project: HBase > Issue Type: Sub-task > Components: Operability, shell >Reporter: stack >Assignee: Umesh Agashe > Fix For: 2.0.0 > > > In AMv2, if a RS is not aligned with Master notions of how the world is, then > the Master will kill the deviant RS (TODO: is forcing compliance via less > radical means -- but that is how it is currently). > The shell currently allows by-passing the Master to make cluster > modifications such as our being able to send a close directly to a > RegionServer for it to execute locally. This facility was used in the past to > do fix-up when Master lost account of Region locations. In the new regime, > such mis-accounting should no longer happen and, should a user mistakenly do > an explicit close against a RS, the consequences will be more than the user > bargained for; the Master will shut down the RS as soon as it reports close > of a Region the master thinks should be open (No independence allowed!). > This issue is to review shell Region and Table manipulation commands to purge > those that by-pass Master or at least to add big warning. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
