[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194220#comment-16194220 ] Anoop Sam John commented on HBASE-18954: On the confs added to new class CoprocessorConfigurations - U want to make this class exposed to CPs (As the original one , the Host , is made private now)? (The new class is missing the InterfaceAudience now) But why we have to expose this? All these confs being used in the conf.xml file by the user only right? I mean why a CP user has to know this constant ? For dynamic loading of CPs, we have APIs right? So am not very sure why these confs to be exposed as a Class level. Yes these are exposed but that is at the conf xml file and all the config names are exposed ones. > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194216#comment-16194216 ] Pankaj Kumar edited comment on HBASE-18923 at 10/6/17 6:40 AM: --- Above failures have the same cause as HBASE-18934, https://builds.apache.org/job/PreCommit-HBASE-Build/8948/artifact/patchprocess/patch-javac-3.0.0-alpha4.txt was (Author: pankaj2461): https://builds.apache.org/job/PreCommit-HBASE-Build/8948/artifact/patchprocess/patch-javac-3.0.0-alpha4.txt > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Attachments: HBASE-18923-branch-1.patch, HBASE-18923-branch-1-V2.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pankaj Kumar updated HBASE-18923: - Comment: was deleted (was: https://builds.apache.org/job/PreCommit-HBASE-Build/8948/artifact/patchprocess/patch-javac-3.0.0-alpha4.txt) > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Attachments: HBASE-18923-branch-1.patch, HBASE-18923-branch-1-V2.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194216#comment-16194216 ] Pankaj Kumar commented on HBASE-18923: -- https://builds.apache.org/job/PreCommit-HBASE-Build/8948/artifact/patchprocess/patch-javac-3.0.0-alpha4.txt > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Attachments: HBASE-18923-branch-1.patch, HBASE-18923-branch-1-V2.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194217#comment-16194217 ] Pankaj Kumar commented on HBASE-18923: -- https://builds.apache.org/job/PreCommit-HBASE-Build/8948/artifact/patchprocess/patch-javac-3.0.0-alpha4.txt > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Attachments: HBASE-18923-branch-1.patch, HBASE-18923-branch-1-V2.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194215#comment-16194215 ] Sean Busbey commented on HBASE-18934: - yay! for reviewers, this will go to all active branches. > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch, > HBASE-18934-branch-1.v1.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194211#comment-16194211
]
Hadoop QA commented on HBASE-18934:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
33s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
8s{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} mvninstall {color} | {color:green} 2m
2s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
33s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
4s{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} shadedjars {color} | {color:green} 2m
29s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 55s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 32m 41s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18934 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12890657/HBASE-18934-branch-1.v1.patch
|
| Optional Tests | asflicense shadedjars shellcheck shelldocs |
| uname | Linux 0be647626243 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 | branch-1 / 719f546 |
| shellcheck | v0.4.6 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8968/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> precommit on branch-1 isn't supposed to run against hadoop 3
>
>
> Key: HBASE-18934
> URL: https://issues.apache.org/jira/browse/HBASE-18934
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-18934-branch-1.v0.patch,
> HBASE-18934-branch-1.v1.patch
>
>
> Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport
> the efforts to make HBase 2.y work with it. Precommit shouldn't tell
> contributors otherwise.
> see HBASE-18923 for an example of a branch-1 patch that had hadoop 3
> compilation checked.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194210#comment-16194210 ] Anoop Sam John commented on HBASE-18948: And write side CP hooks can even add Tags to Cells. I believe this is what Timeline Server feature is doing. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194209#comment-16194209 ] Anoop Sam John commented on HBASE-18948: bq.We allow clients to build raw cell serializations, potentially including tags, and submit them. I can't say if they are stripped out or not. It is stripped out now. And ya while sending back read response also, at the RPC layer the tags are getting stripped off ( by Codec) And ya replication uses special Codec so as to pass Tags. And ReplicationEP will be getting this used I believe. And YES. When the read cells are passed through the CP hooks or a CP code is doing a read, the Tags will be visible in the Cells. Only at the RPC layer the stripping happens. I agree that this is a temp solution for not exposing the security related tags to client. But that is not full fledged. Planned to do cleanup and completion of this for 2.0 but seems wont happen as am in to some thing else now. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions
[ https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194201#comment-16194201 ] Anoop Sam John commented on HBASE-16417: bq.So since these are in-memory compactions the effect of HDD/SSDs does it come from the fact as how fast these segments in the pipeline are released after flushes? Looks like that is based on the fact that how much we delay flush of certain data and so possibly reading back most of the data from memory only and not from HDD/SSD files. The more eager way we do in memory flush, the lesser will be the heap size of the memstore and so the flush. So these tests were done with changing back to the old way of per region flush decision based on heap size NOT on data size? 2% seems very much eager. The more gain u r seeing because the data size is so small. The Key + Data size comes much lesser than the overhead because of CSLM addition. So in effect each flatten reducing the heap size occupancy almost by half. The more the data size, the lesser will be the gain. To have a fair eval what should be the val size to used? Any suggestions [~stack]? Nice tests and detailed report. > In-Memory MemStore Policy for Flattening and Compactions > > > Key: HBASE-16417 > URL: https://issues.apache.org/jira/browse/HBASE-16417 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Eshcar Hillel > Fix For: 3.0.0 > > Attachments: HBASE-16417.01.patch, HBASE-16417 - Adaptive Compaction > Policy - 20171001.pdf, HBASE-16417-benchmarkresults-20161101.pdf, > HBASE-16417-benchmarkresults-20161110.pdf, > HBASE-16417-benchmarkresults-20161123.pdf, > HBASE-16417-benchmarkresults-20161205.pdf, > HBASE-16417-benchmarkresults-20170309.pdf, > HBASE-16417-benchmarkresults-20170317.pdf, HBASE-16417 - parameter tuning - > 20171001.pdf, HBASE-16417-V01.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
[ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194196#comment-16194196 ] Anoop Sam John commented on HBASE-18703: bq.Regarding giving user an option to specify read or write lock, depending on use case this can be implemented in future. Currently I am trying retain functionality with single code path. Most use case need exclusive/ write locks on multiple rows. Do you have any use case for which shared lock on multiple rows is enough? Not directly.. As per what [~chia7712] said, the RowProcessor was writing one row based on a read and condition check on some other rows. So I believe, in such cases, users might be taking write lock on those rows which has to be evaluated and read lock on the one which has to be written data to. Its fine we can check that later. In this patch, the big part is the (wrt #lines change) is the refactoring of the doMiniBatchMuatate() method by extracting some private methods. May be that itself u can do as a separate jira as that will need careful eye. And then go with unify the this with the processRowsWithLock > Inconsistent behavior for preBatchMutate in doMiniBatchMutate and > processRowsWithLocks > -- > > Key: HBASE-18703 > URL: https://issues.apache.org/jira/browse/HBASE-18703 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang >Assignee: Umesh Agashe >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18703.master.001.patch, > hbase-18703.master.002.patch, hbase-18703.master.003.patch, > hbase-18703.master.004.patch, hbase-18703.master.005.patch, > hbase-18703.master.005.patch, hbase-18703.master.005.patch, > hbase-18703.master.006.patch, hbase-18703.master.007.patch > > > In doMiniBatchMutate, the preBatchMutate is called before building WAL, but > in processRowsWithLocks, we suggest the RowProcessor implementation to build > WAL in process method, which is ahead of preBatchMutate. > If a CP modifies the mutations, especially if it removes some cells from the > mutations, then the behavior of processRowsWithLocks is broken. The changes > applied to memstore and WAL will be different. And there is no way to remove > entries from a WALEdit through CP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
[ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194194#comment-16194194 ] Anoop Sam John commented on HBASE-18703: Seems the RowProcessor way of implementation is possible with the new APIs that we give + using some of the CP hook. So am +1 for removing it. Given it is LimitedPrivate remove or deprecate 1st and then remove? If we can remove RowProcessor , we can remove getRowLock being exposed to CPs. Ya we are giving new APIs which takes rowsToLock so whichever rows need additional lock, user can pass them. It would be really great if we can remove this row lock expose. And so startRegionOp (This is because we are exposing getting row lock). We will have to write one eg: use case with the new APIs and CPs to show how an old RowProcessor way is achievable now. And we will have the unify path. So at least 4 jiras may be there :-) > Inconsistent behavior for preBatchMutate in doMiniBatchMutate and > processRowsWithLocks > -- > > Key: HBASE-18703 > URL: https://issues.apache.org/jira/browse/HBASE-18703 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang >Assignee: Umesh Agashe >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18703.master.001.patch, > hbase-18703.master.002.patch, hbase-18703.master.003.patch, > hbase-18703.master.004.patch, hbase-18703.master.005.patch, > hbase-18703.master.005.patch, hbase-18703.master.005.patch, > hbase-18703.master.006.patch, hbase-18703.master.007.patch > > > In doMiniBatchMutate, the preBatchMutate is called before building WAL, but > in processRowsWithLocks, we suggest the RowProcessor implementation to build > WAL in process method, which is ahead of preBatchMutate. > If a CP modifies the mutations, especially if it removes some cells from the > mutations, then the behavior of processRowsWithLocks is broken. The changes > applied to memstore and WAL will be different. And there is no way to remove > entries from a WALEdit through CP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18934: Attachment: HBASE-18934-branch-1.v1.patch -1 - move hadoopcheck version checks into the hadoopcheck test rather than in the global inits. > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch, > HBASE-18934-branch-1.v1.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194191#comment-16194191 ] Sean Busbey commented on HBASE-18934: - this also means we weren't checking the correct hadoop 2 versions on branch 1. :( :( > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch, > HBASE-18934-branch-1.v1.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18934: Status: Patch Available (was: In Progress) > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch, > HBASE-18934-branch-1.v1.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194192#comment-16194192 ] Hadoop QA commented on HBASE-18934: --- (!) 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/8968/console in case of problems. > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch, > HBASE-18934-branch-1.v1.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[ https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194187#comment-16194187 ] Anoop Sam John commented on HBASE-18931: +1. Nice one. > Make ObserverContext an interface and remove private/testing methods > > > Key: HBASE-18931 > URL: https://issues.apache.org/jira/browse/HBASE-18931 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18931.master.001.patch, > HBASE-18931.master.002.patch, HBASE-18931.master.003.patch > > > ObserverContext is IA.LimitedPrivate because CP implementations want > getEnvironment(), bypass(), etc. > We can split interface and implementations (suggested by [~Apache9]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[ https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194187#comment-16194187 ] Anoop Sam John edited comment on HBASE-18931 at 10/6/17 5:57 AM: - +1. Nice cleanup. was (Author: anoop.hbase): +1. Nice one. > Make ObserverContext an interface and remove private/testing methods > > > Key: HBASE-18931 > URL: https://issues.apache.org/jira/browse/HBASE-18931 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18931.master.001.patch, > HBASE-18931.master.002.patch, HBASE-18931.master.003.patch > > > ObserverContext is IA.LimitedPrivate because CP implementations want > getEnvironment(), bypass(), etc. > We can split interface and implementations (suggested by [~Apache9]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18934: Status: In Progress (was: Patch Available) > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194182#comment-16194182 ] ramkrishna.s.vasudevan commented on HBASE-18945: bq.Even if Store and StoreFile also expose it is just fine only. Ya . But I was telling in terms of ease of use for CPs users. Anyway all the layers the compareator is going to be same except for the META region. > Make a Public interface for CellComparator > -- > > Key: HBASE-18945 > URL: https://issues.apache.org/jira/browse/HBASE-18945 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194180#comment-16194180
]
Sean Busbey commented on HBASE-18934:
-
{code}
04:11:48 JAVA_HOME: /home/jenkins/tools/java/latest1.7 does not exist.
Dockermode: attempting to switch to another.
04:11:48 Setting /usr/lib/jvm/java-7-openjdk-amd64 as the JAVA_HOME.
04:11:49 [Fri Oct 6 04:11:48 UTC 2017 INFO]: setting Hadoop versions to test
based on master/feature branch rules.
04:11:49 Modes: MultiJDK Jenkins Robot Docker ResetRepo UnitTests
04:11:49 Processing: HBASE-18934
04:11:51 HBASE-18934 patch is being downloaded at Fri Oct 6 04:11:50 UTC 2017
from
04:11:51
https://issues.apache.org/jira/secure/attachment/12890645/HBASE-18934-branch-1.v0.patch
-> Downloaded
04:11:51
04:11:51
04:11:51
04:11:51
04:11:51 Confirming git environment
04:11:51
04:11:51
04:11:51
04:11:51
04:11:51 HEAD is now at 719f546 HBASE-18940 include project pylint configs in
source artifact.
04:11:52 Switched to branch 'master'
04:11:52 Your branch is up-to-date with 'origin/master'.
04:11:55 Current branch master is up to date.
04:11:56 Switched to branch 'branch-1'
04:11:56 Your branch is up-to-date with 'origin/branch-1'.
04:11:57 Current branch branch-1 is up to date.
04:11:57 Testing HBASE-18934 patch on branch-1.
04:11:57
04:11:57
04:11:57
04:11:57
04:11:57 Re-exec mode detected. Continuing.
04:11:57
04:11:57
{code}
Ah. our init is before the patch branch is determined. big frowns.
> precommit on branch-1 isn't supposed to run against hadoop 3
>
>
> Key: HBASE-18934
> URL: https://issues.apache.org/jira/browse/HBASE-18934
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-18934-branch-1.v0.patch
>
>
> Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport
> the efforts to make HBase 2.y work with it. Precommit shouldn't tell
> contributors otherwise.
> see HBASE-18923 for an example of a branch-1 patch that had hadoop 3
> compilation checked.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194179#comment-16194179 ] Anoop Sam John commented on HBASE-18945: What I mean is the Comparator that we return from Store will be same as that we have in Region right? And again in StoreFile also. The comparator will be diff at Table level. ie. for META a special one. Thats it. That is why I was asking .. Any way not a big deal. Even if Store and StoreFile also expose it is just fine only. bq.Should we purge the Serializable if we prepare to make CellComparator IA.Public? May be we can. We are not serializing the comparator object. In HFiles, we just write the comparator class name which is used > Make a Public interface for CellComparator > -- > > Key: HBASE-18945 > URL: https://issues.apache.org/jira/browse/HBASE-18945 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18601) Update Htrace to 4.2
[
https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194178#comment-16194178
]
Hadoop QA commented on HBASE-18601:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
43s{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 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
40s{color} | {color:blue} Maven dependency ordering for branch {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} 20m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 13m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
24s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 27m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 17m
35s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
38s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
37s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 1m
37s{color} | {color:red} hbase-spark in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 20m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 20m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 13m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
7s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint 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} xml {color} | {color:green} 1m
3s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
42s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
65m 37s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-testing-util . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 14m
5s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
26s{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
17s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:gre
[jira] [Commented] (HBASE-18752) Recalculate the TimeRange in flushing snapshot to store file
[ https://issues.apache.org/jira/browse/HBASE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194177#comment-16194177 ] Anoop Sam John commented on HBASE-18752: Thanks.. Am generally +1 on this. Still would be nice to run PE random write tests for a bit longer duration of say 10 mns to see the impact of the overhead in flush. Also in COmpacting MemStore when Policy is EAGER, for each of the ImmutableSegment creation, we will recalculate this TR? There also dropping of dup cells etc happens. Pls double check once. May be a test case also for that would be nice to have. > Recalculate the TimeRange in flushing snapshot to store file > > > Key: HBASE-18752 > URL: https://issues.apache.org/jira/browse/HBASE-18752 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18752.v0.patch, HBASE-18752.v1.patch > > > We drop superfluous cells in flushing, hence the TimeRange from snapshot is > inaccurate for the storefile. We should recalculate the TimeRange for the > storefile, but the side-effect is the extra cost - we need to extract the > timestamp from cell (ByteBufferCell). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18921) Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
[ https://issues.apache.org/jira/browse/HBASE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maytee Chinavanichkit updated HBASE-18921: -- Status: Patch Available (was: Open) > Result.current() throws ArrayIndexOutOfBoundsException after calling advance() > -- > > Key: HBASE-18921 > URL: https://issues.apache.org/jira/browse/HBASE-18921 > Project: HBase > Issue Type: Bug >Reporter: Maytee Chinavanichkit >Assignee: Maytee Chinavanichkit >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18921.master.001.patch, > HBASE-18921.master.002.patch, master.patch > > > On a Result object, if current() method is called after advance() returns > false, this throws an ArrayIndexOutOfBoundsException. The expectation here is > that it should return a null value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18921) Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
[
https://issues.apache.org/jira/browse/HBASE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194156#comment-16194156
]
Maytee Chinavanichkit commented on HBASE-18921:
---
[~chia7712] Would you know why other test in this file do not have the
{{@Test}}?
> Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
> --
>
> Key: HBASE-18921
> URL: https://issues.apache.org/jira/browse/HBASE-18921
> Project: HBase
> Issue Type: Bug
>Reporter: Maytee Chinavanichkit
>Assignee: Maytee Chinavanichkit
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
> Attachments: HBASE-18921.master.001.patch,
> HBASE-18921.master.002.patch, master.patch
>
>
> On a Result object, if current() method is called after advance() returns
> false, this throws an ArrayIndexOutOfBoundsException. The expectation here is
> that it should return a null value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18921) Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
[ https://issues.apache.org/jira/browse/HBASE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maytee Chinavanichkit updated HBASE-18921: -- Attachment: HBASE-18921.master.002.patch > Result.current() throws ArrayIndexOutOfBoundsException after calling advance() > -- > > Key: HBASE-18921 > URL: https://issues.apache.org/jira/browse/HBASE-18921 > Project: HBase > Issue Type: Bug >Reporter: Maytee Chinavanichkit >Assignee: Maytee Chinavanichkit >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18921.master.001.patch, > HBASE-18921.master.002.patch, master.patch > > > On a Result object, if current() method is called after advance() returns > false, this throws an ArrayIndexOutOfBoundsException. The expectation here is > that it should return a null value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18921) Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
[ https://issues.apache.org/jira/browse/HBASE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maytee Chinavanichkit updated HBASE-18921: -- Status: Open (was: Patch Available) > Result.current() throws ArrayIndexOutOfBoundsException after calling advance() > -- > > Key: HBASE-18921 > URL: https://issues.apache.org/jira/browse/HBASE-18921 > Project: HBase > Issue Type: Bug >Reporter: Maytee Chinavanichkit >Assignee: Maytee Chinavanichkit >Priority: Minor > Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7 > > Attachments: HBASE-18921.master.001.patch, > HBASE-18921.master.002.patch, master.patch > > > On a Result object, if current() method is called after advance() returns > false, this throws an ArrayIndexOutOfBoundsException. The expectation here is > that it should return a null value. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194151#comment-16194151 ] ramkrishna.s.vasudevan edited comment on HBASE-18946 at 10/6/17 5:19 AM: - [~huaxiang] Thanks for the update. Great that you already feel this change will solve the problem. I was checking this issue but got pulled to something else. Will be back here and to check your suggestion. And yes we need to check all related areas and also other related branches. was (Author: ram_krish): [~huaxiang] Thanks for the update. Great that you already feel this change will solve the problem. I was checking this issue but got pulled to something else. Will be back here and to check your suggestion. And yes we need to check all related areas and also other related branches also. > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18946) Stochastic load balancer assigns replica regions to the same RS
[ https://issues.apache.org/jira/browse/HBASE-18946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194151#comment-16194151 ] ramkrishna.s.vasudevan commented on HBASE-18946: [~huaxiang] Thanks for the update. Great that you already feel this change will solve the problem. I was checking this issue but got pulled to something else. Will be back here and to check your suggestion. And yes we need to check all related areas and also other related branches also. > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194150#comment-16194150 ] ramkrishna.s.vasudevan commented on HBASE-18945: bq.We have it in Region, Store, StoreFile etc. Reading the code I think for having Comparator in Store or not depends on what type of InternalScanner are we going to expose. How ever if the new interface is only exposing some restrcited but powerful APIs then it is still fine to expose in Store? So that CPs in case they need to filter out or do some processing on KVs can do it at the InternalScanner level? StoreFile level we may not need it IMHO. bq.Should we purge the Serializable if we prepare to make CellComparator IA.Public? Is there any harm in having it Serializable? Am not very sure on this. > Make a Public interface for CellComparator > -- > > Key: HBASE-18945 > URL: https://issues.apache.org/jira/browse/HBASE-18945 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18752) Recalculate the TimeRange in flushing snapshot to store file
[ https://issues.apache.org/jira/browse/HBASE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194148#comment-16194148 ] ramkrishna.s.vasudevan commented on HBASE-18752: Thanks [~chia7712]. The new test case covers the multi version case also. > Recalculate the TimeRange in flushing snapshot to store file > > > Key: HBASE-18752 > URL: https://issues.apache.org/jira/browse/HBASE-18752 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18752.v0.patch, HBASE-18752.v1.patch > > > We drop superfluous cells in flushing, hence the TimeRange from snapshot is > inaccurate for the storefile. We should recalculate the TimeRange for the > storefile, but the side-effect is the extra cost - we need to extract the > timestamp from cell (ByteBufferCell). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16417) In-Memory MemStore Policy for Flattening and Compactions
[ https://issues.apache.org/jira/browse/HBASE-16417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194147#comment-16194147 ] ramkrishna.s.vasudevan commented on HBASE-16417: I read the doc first not seen the patch yet. So since these are in-memory compactions the effect of HDD/SSDs does it come from the fact as how fast these segments in the pipeline are released after flushes? As said in the doc scans are affected if the number of segments in pipeline are more and so is the case with flushes also which needs to read the segments? Because here we capture the throughput of writes and flushes are not in the hot path so does it mean that we get blocking updates and the throughput depends on how fast the blocking udpates are cleared and that depends on the segment count? > In-Memory MemStore Policy for Flattening and Compactions > > > Key: HBASE-16417 > URL: https://issues.apache.org/jira/browse/HBASE-16417 > Project: HBase > Issue Type: Sub-task >Reporter: Anastasia Braginsky >Assignee: Eshcar Hillel > Fix For: 3.0.0 > > Attachments: HBASE-16417.01.patch, HBASE-16417 - Adaptive Compaction > Policy - 20171001.pdf, HBASE-16417-benchmarkresults-20161101.pdf, > HBASE-16417-benchmarkresults-20161110.pdf, > HBASE-16417-benchmarkresults-20161123.pdf, > HBASE-16417-benchmarkresults-20161205.pdf, > HBASE-16417-benchmarkresults-20170309.pdf, > HBASE-16417-benchmarkresults-20170317.pdf, HBASE-16417 - parameter tuning - > 20171001.pdf, HBASE-16417-V01.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[
https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194143#comment-16194143
]
Hadoop QA commented on HBASE-18954:
---
| (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 84 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
35s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
13s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
5s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m
26s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
41s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 2m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
38s{color} | {color:red} patch has 10 errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
37m 7s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}113m
54s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
29s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 12m
6s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m
40s{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 10m
5s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m
3s{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:red}-1{color} | {color:red} asflicense {color} | {color:red} 1m
32s{color} | {color:red} The patch generated 1 ASF License warnings. {color} |
| {color:black}{color} | {color:black} {color} | {color:black}227m 40s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-1895
[jira] [Commented] (HBASE-18925) Need updated mockito for using java optional
[
https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194126#comment-16194126
]
Hadoop QA commented on HBASE-18925:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
18s{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 13 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 13m
16s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
58s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m
15s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
32s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
16s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 8m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m
13s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
16s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
37s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
42m 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-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 10m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
22s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
11s{color} | {color:green} hbase-metrics-api in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
18s{color} | {color:green} hbase-metrics in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
58s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 68m 31s{col
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[
https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194125#comment-16194125
]
Hadoop QA commented on HBASE-18934:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
36s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
9s{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} mvninstall {color} | {color:green} 2m
5s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {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} shadedjars {color} | {color:green} 2m
27s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 18m
24s{color} | {color:red} The patch causes 178 errors with Hadoop v3.0.0-alpha4.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
18s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 24m 21s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18934 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12890645/HBASE-18934-branch-1.v0.patch
|
| Optional Tests | asflicense shadedjars shellcheck shelldocs |
| uname | Linux b1d7eab94873 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | branch-1 / 719f546 |
| shellcheck | v0.4.6 |
| modules | C: . U: . |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8966/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> precommit on branch-1 isn't supposed to run against hadoop 3
>
>
> Key: HBASE-18934
> URL: https://issues.apache.org/jira/browse/HBASE-18934
> Project: HBase
> Issue Type: Bug
> Components: test
>Affects Versions: 1.5.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Attachments: HBASE-18934-branch-1.v0.patch
>
>
> Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport
> the efforts to make HBase 2.y work with it. Precommit shouldn't tell
> contributors otherwise.
> see HBASE-18923 for an example of a branch-1 patch that had hadoop 3
> compilation checked.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18925) Need updated mockito for using java optional
[
https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194117#comment-16194117
]
Hadoop QA commented on HBASE-18925:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 13 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
28s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
8s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m
18s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
17s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
15s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
22s{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
15s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
34m 43s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
21s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
10s{color} | {color:green} hbase-metrics-api in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
17s{color} | {color:green} hbase-metrics in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
40s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 81m 39s{color}
| {color:red} hbase-server in the patch
[jira] [Commented] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194113#comment-16194113 ] Hadoop QA commented on HBASE-18934: --- (!) 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/8966/console in case of problems. > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18934: Status: Patch Available (was: Open) > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18934: Attachment: HBASE-18934-branch-1.v0.patch -0 - add some output > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > Attachments: HBASE-18934-branch-1.v0.patch > > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18752) Recalculate the TimeRange in flushing snapshot to store file
[ https://issues.apache.org/jira/browse/HBASE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194100#comment-16194100 ] Chia-Ping Tsai edited comment on HBASE-18752 at 10/6/17 3:27 AM: - bq. Any chance for a perf test ? sure. Will run the perf test at weekend. was (Author: chia7712): bq. Any chance for a perf test ? sure. Will run the perf test at weekends. > Recalculate the TimeRange in flushing snapshot to store file > > > Key: HBASE-18752 > URL: https://issues.apache.org/jira/browse/HBASE-18752 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18752.v0.patch, HBASE-18752.v1.patch > > > We drop superfluous cells in flushing, hence the TimeRange from snapshot is > inaccurate for the storefile. We should recalculate the TimeRange for the > storefile, but the side-effect is the extra cost - we need to extract the > timestamp from cell (ByteBufferCell). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18752) Recalculate the TimeRange in flushing snapshot to store file
[ https://issues.apache.org/jira/browse/HBASE-18752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194100#comment-16194100 ] Chia-Ping Tsai commented on HBASE-18752: bq. Any chance for a perf test ? sure. Will run the perf test at weekends. > Recalculate the TimeRange in flushing snapshot to store file > > > Key: HBASE-18752 > URL: https://issues.apache.org/jira/browse/HBASE-18752 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Chia-Ping Tsai > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18752.v0.patch, HBASE-18752.v1.patch > > > We drop superfluous cells in flushing, hence the TimeRange from snapshot is > inaccurate for the storefile. We should recalculate the TimeRange for the > storefile, but the side-effect is the extra cost - we need to extract the > timestamp from cell (ByteBufferCell). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18921) Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
[
https://issues.apache.org/jira/browse/HBASE-18921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194078#comment-16194078
]
Chia-Ping Tsai commented on HBASE-18921:
{code}
+ public void testCurrentOnEmptyCell() throws IOException {
+Result r = Result.create(new Cell[0]);
+assertFalse(r.advance());
+assertNull(r.current());
+ }
+
+ public void testAdvanceTwiceOnEmptyCell() throws IOException {
+Result r = Result.create(new Cell[0]);
+assertFalse(r.advance());
+try {
+ r.advance();
+ fail("NoSuchElementException should have been thrown!");
+} catch (NoSuchElementException ex) {
+ LOG.debug("As expected: " + ex.getMessage());
+}
+ }
{code}
Please add the {{@Test}} annotation.
> Result.current() throws ArrayIndexOutOfBoundsException after calling advance()
> --
>
> Key: HBASE-18921
> URL: https://issues.apache.org/jira/browse/HBASE-18921
> Project: HBase
> Issue Type: Bug
>Reporter: Maytee Chinavanichkit
>Assignee: Maytee Chinavanichkit
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
> Attachments: HBASE-18921.master.001.patch, master.patch
>
>
> On a Result object, if current() method is called after advance() returns
> false, this throws an ArrayIndexOutOfBoundsException. The expectation here is
> that it should return a null value.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18911) Unify Admin and AsyncAdmin's methods name
[ https://issues.apache.org/jira/browse/HBASE-18911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194070#comment-16194070 ] Chia-Ping Tsai commented on HBASE-18911: Personally, I prefer the get/set/is pattern. > Unify Admin and AsyncAdmin's methods name > - > > Key: HBASE-18911 > URL: https://issues.apache.org/jira/browse/HBASE-18911 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > > Different Methods > || AsyncAdmin || Admin || unified name || > | listTables | listTableDescriptors | listTableDescriptors | > | getOnlineRegions | getRegions | getRegions | > | getTableRegions | getRegions | getRegions | > | getTableDescriptor | getDescriptor | getDescriptor | > | getRegionLoads | getRegionLoad | getRegionLoads | > | execProcedureWithRet | execProcedureWithReturn | execProcedureWithReturn | > | setNormalizerOn | normalizerSwitch | setNormalizerOn | > | isNormalizerOn | isNormalizerEnabled | isNormalizerOn | > | setBalancerOn | balancerSwitch | setBalancerOn | > | isBalancerOn | isBalancerEnabled | isBalancerOn | > | setCleanerChoreOn | cleanerChoreSwitch | setCleanerChoreOn | > | isCleanerChoreOn | isCleanerChoreEnabled | isCleanerChoreOn | > | setSplitOn/setMergeOn | splitOrMergeEnabledSwitch | setSplitOn/setMergeOn | > Methods only in AsyncAdmin > || AsyncAdmin || > | isSplitOn | > | isMergeOn | > | majorCompactRegionServer | > | stopRegionServer | -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18601) Update Htrace to 4.2
[ https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-18601: - Status: Patch Available (was: Open) > Update Htrace to 4.2 > > > Key: HBASE-18601 > URL: https://issues.apache.org/jira/browse/HBASE-18601 > Project: HBase > Issue Type: Task >Affects Versions: 2.0.0, 3.0.0 >Reporter: Tamas Penzes >Assignee: Tamas Penzes > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18601.master.001.patch, > HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, > HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, > HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, > HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.008.patch > > > HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, > the upgrade to 4.x is not trivial and would take time. It might not worth to > keep it in this state, so would be better to remove it. > Of course it doesn't mean tracing would be useless, just that in this form > the use of HTrace 3.2 might not add any value to the project and fixing it > would be far too much effort. > - > Based on the decision of the community we keep htrace now and update version -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18601) Update Htrace to 4.2
[ https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-18601: - Status: Open (was: Patch Available) > Update Htrace to 4.2 > > > Key: HBASE-18601 > URL: https://issues.apache.org/jira/browse/HBASE-18601 > Project: HBase > Issue Type: Task >Affects Versions: 2.0.0, 3.0.0 >Reporter: Tamas Penzes >Assignee: Tamas Penzes > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18601.master.001.patch, > HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, > HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, > HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, > HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.008.patch > > > HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, > the upgrade to 4.x is not trivial and would take time. It might not worth to > keep it in this state, so would be better to remove it. > Of course it doesn't mean tracing would be useless, just that in this form > the use of HTrace 3.2 might not add any value to the project and fixing it > would be far too much effort. > - > Based on the decision of the community we keep htrace now and update version -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[
https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194046#comment-16194046
]
Hadoop QA commented on HBASE-18108:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
19s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
1s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 1 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
34s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
41s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
2s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
40m 10s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
17s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}102m
51s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
31s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}168m 23s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18108 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12890611/HBASE-18108.master.001.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit xml findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 720f73a57d12 3.13.0-117-generic #164-Ubuntu SMP Fri Apr 7
11:05:26 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[
https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194041#comment-16194041
]
Vladimir Rodionov commented on HBASE-18843:
---
{quote}
Apply patches from HDFS-12599 and HADOOP-14930
{quote}
Who is going to take care of this issue on a Hadoop side? It seems that w/o
these patches HBase 2.0 is blocked on Hadoop3?
> Add DistCp support to incremental backup with bulk loading
> --
>
> Key: HBASE-18843
> URL: https://issues.apache.org/jira/browse/HBASE-18843
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch,
> HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch,
> HBASE-18843-v7.patch
>
>
> Currently, we copy bulk loaded files to backup one-by-one on a client side
> (where backup create runs). This has to be replaced with DistCp copying.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18090) Improve TableSnapshotInputFormat to allow more multiple mappers per region
[ https://issues.apache.org/jira/browse/HBASE-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194040#comment-16194040 ] xinxin fan commented on HBASE-18090: backport to branch-1 > Improve TableSnapshotInputFormat to allow more multiple mappers per region > -- > > Key: HBASE-18090 > URL: https://issues.apache.org/jira/browse/HBASE-18090 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 3.0.0 >Reporter: Mikhail Antonov >Assignee: xinxin fan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18090-branch-1.3-v1.patch, > HBASE-18090-branch-1.3-v2.patch, HBASE-18090.branch-1.patch, > HBASE-18090-V3-master.patch, HBASE-18090-V4-master.patch, > HBASE-18090-V5-master.patch > > > TableSnapshotInputFormat runs one map task per region in the table snapshot. > This places unnecessary restriction that the region layout of the original > table needs to take the processing resources available to MR job into > consideration. Allowing to run multiple mappers per region (assuming > reasonably even key distribution) would be useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18090) Improve TableSnapshotInputFormat to allow more multiple mappers per region
[ https://issues.apache.org/jira/browse/HBASE-18090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xinxin fan updated HBASE-18090: --- Attachment: HBASE-18090.branch-1.patch > Improve TableSnapshotInputFormat to allow more multiple mappers per region > -- > > Key: HBASE-18090 > URL: https://issues.apache.org/jira/browse/HBASE-18090 > Project: HBase > Issue Type: Improvement > Components: mapreduce >Affects Versions: 3.0.0 >Reporter: Mikhail Antonov >Assignee: xinxin fan > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18090-branch-1.3-v1.patch, > HBASE-18090-branch-1.3-v2.patch, HBASE-18090.branch-1.patch, > HBASE-18090-V3-master.patch, HBASE-18090-V4-master.patch, > HBASE-18090-V5-master.patch > > > TableSnapshotInputFormat runs one map task per region in the table snapshot. > This places unnecessary restriction that the region layout of the original > table needs to take the processing resources available to MR job into > consideration. Allowing to run multiple mappers per region (assuming > reasonably even key distribution) would be useful. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[
https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194037#comment-16194037
]
Hadoop QA commented on HBASE-18931:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 5 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 5m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
53s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
45s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
6s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
4s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
45m 43s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
41s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
29s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}117m
41s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
19s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}188m 6s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-18931 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12890603/HBASE-18931.master.003.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 7914c7c275a7 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision | master / bafbade |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/8958/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/8958/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Make ObserverContext an interface and remove private/testing met
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194034#comment-16194034 ] Ted Yu commented on HBASE-18843: Checkout branch-3.0.0-beta1 branch of hadoop Apply patches from HDFS-12599 and HADOOP-14930 'mvn install -DskipTests' Then go to hbase master branch, use the two mvn commands shown above. > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[ https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194030#comment-16194030 ] Vladimir Rodionov commented on HBASE-18843: --- [~tedyu], how can I reproduce this on master? > Add DistCp support to incremental backup with bulk loading > -- > > Key: HBASE-18843 > URL: https://issues.apache.org/jira/browse/HBASE-18843 > Project: HBase > Issue Type: Improvement >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch, > HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch, > HBASE-18843-v7.patch > > > Currently, we copy bulk loaded files to backup one-by-one on a client side > (where backup create runs). This has to be replaced with DistCp copying. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18954: - Attachment: HBASE-18954.master.001.patch > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18954: - Status: Patch Available (was: Open) > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18954: - Release Note: - Make CoprocessorHost and its implementations InterfaceAudience.Private - Configurations from "CoprocessorHost" have been moved to new "CoprocessorConfigurations" class. was: - Make CoprocessorHost and its implementations InterfaceAudience.Private - Configurations from "CoprocessorHost" have been moved to "Coprocessor" > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194008#comment-16194008 ] Appy commented on HBASE-18954: -- At first, i moved all the config name variables to Coprocessor class. Was about to submit the patch, but then moving these constants to hbase-client package seemed bad because that's adding unnecessary dependency edge between two modules. Second thought was, moving them to a new and separate CoprocessorConfigs class in hbase-server/o/a/h/h/coprocessor i.e. next to CoprocessorHost, but that is the same pattern as HConstants, and the one we regret. In the end, it seems like it's best to keep these configs close to the context they are used. So basically, "hbase.coprocessor.region.classes" should go in the RegionCpHost. What do others think? [~Apache9], [~anoopsamjohn] [~stack] It should either be option 2, if exposing it to third party is important, or option 3, if you think that confs are for hbase-site.xml and not exposing as constants is fine. > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16194003#comment-16194003
]
Hadoop QA commented on HBASE-16338:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
20s{color} | {color:blue} Docker mode activated. {color} |
| {color: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 7 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
36s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 9m
45s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-resource-bundle hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m
52s{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} 5m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 4m
50s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
59s{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
8s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
33s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
23s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 9m
8s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 12m
0s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 14m
56s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 18m
4s{color} | {color:red} The patch causes 10 errors with Hadoop v2.6.5. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-resource-bundle hbase-shaded/hbase-shaded-mapreduce . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
33s{color} | {color:green} hbase-client in the pa
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193994#comment-16193994 ] Appy commented on HBASE-18954: -- Interesting, MasterCpHost and WALCpHost are already IA.Private. Only CpHost, RegionCpHost, and RegionServerCpHost are IA.LimitedPrivate > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[ https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18931: - Release Note: Changes ObserverContext from a class to an interface and hides away constructor, testing functions and other internal-only functions in the implementation class. > Make ObserverContext an interface and remove private/testing methods > > > Key: HBASE-18931 > URL: https://issues.apache.org/jira/browse/HBASE-18931 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18931.master.001.patch, > HBASE-18931.master.002.patch, HBASE-18931.master.003.patch > > > ObserverContext is IA.LimitedPrivate because CP implementations want > getEnvironment(), bypass(), etc. > We can split interface and implementations (suggested by [~Apache9]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[ https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18931: - Labels: incompatible (was: ) > Make ObserverContext an interface and remove private/testing methods > > > Key: HBASE-18931 > URL: https://issues.apache.org/jira/browse/HBASE-18931 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18931.master.001.patch, > HBASE-18931.master.002.patch, HBASE-18931.master.003.patch > > > ObserverContext is IA.LimitedPrivate because CP implementations want > getEnvironment(), bypass(), etc. > We can split interface and implementations (suggested by [~Apache9]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy reassigned HBASE-18954: Assignee: Appy Release Note: - Make CoprocessorHost and its implementations InterfaceAudience.Private - Configurations from "CoprocessorHost" have been moved to "Coprocessor" > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18954: - Labels: incompatible (was: ) > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193985#comment-16193985
]
Hadoop QA commented on HBASE-12260:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
24s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 41 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
25s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
54s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
9s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
23s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
25s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
15s{color} | {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
25s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m
14s{color} | {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 25s{color} |
{color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} cc {color} | {color:red} 0m 14s{color} |
{color:red} hbase-rsgroup in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 25s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 14s{color}
| {color:red} hbase-rsgroup in the patch failed. {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
32s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
49s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} shadedjars {color} | {color:red} 2m
19s{color} | {color:red} patch has 14 errors when building our shaded
downstream artifacts. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m
41s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m
3s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m
21s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.3. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m
40s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.4. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m
57s{color} | {color:red} The patch causes 14 errors with Hadoop v2.6.5. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 10m
16s{color} | {color:red} The patch causes 14 errors with Hadoop v2.7.1. {color}
|
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 11m
33s{color} | {c
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[
https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193950#comment-16193950
]
Appy commented on HBASE-18954:
--
So in MasterCoprocessorEnvironment, we give out MasterServices which is marked
Private (being tackled in HBASE-12260). And MasterServices gives out
{{MasterCoprocessorHost getMasterCoprocessorHost()}}. So basically, CP
implementations were able to get hold of hosts. Not good!
However, that jira is removing master CP getter. :)
Figuring out what needs to be moved out of *CpHost into separate LimitedPrivate
zone so that we an make these hosts private.
> Make *CoprocessorHost classes private
> -
>
> Key: HBASE-18954
> URL: https://issues.apache.org/jira/browse/HBASE-18954
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Appy
> Fix For: 2.0.0-alpha-4
>
>
> Move out configuration name constants (into Coprocessor class?) and made Host
> classes private.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193939#comment-16193939
]
Appy commented on HBASE-12260:
--
Was briefly looking at patch to see the fate of
MasterServices#getMasterCoprocessorHost(). (So this is not a code review :) )
One thing that came to attention was,
{noformat}
return MasterProcedureUtil.submitProcedure(
new MasterProcedureUtil.NonceProcedureRunnable(this, nonceGroup, nonce)
{
@Override
protected void run() throws IOException {
getMasterCoprocessorHost().preXXX(...);
getMasterCoprocessorHost().postXXX(...);
}
{noformat}
Since these nonce runnables are being tied to masterCpHost by the virtue of
being anonymous classes, can we get rid of {{HMaster master}} in
NonceProcedureRunnable altogether?
> MasterServices - remove from coprocessor API (Discuss)
> --
>
> Key: HBASE-12260
> URL: https://issues.apache.org/jira/browse/HBASE-12260
> Project: HBase
> Issue Type: Sub-task
> Components: master
>Reporter: ryan rawson
>Assignee: stack
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-12260.master.001.patch,
> HBASE-12260.master.002.patch
>
>
> A major issue with MasterServices is the MasterCoprocessorEnvironment exposes
> this class even though MasterServices is tagged with
> @InterfaceAudience.Private
> This means that the entire internals of the HMaster is essentially part of
> the coprocessor API. Many of the classes returned by the MasterServices API
> are highly internal, extremely powerful, and subject to constant change.
> Perhaps a new API to replace MasterServices that is use-case focused, and
> justified based on real world co-processors would suit things better.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193926#comment-16193926 ] stack commented on HBASE-12260: --- .002 compiles. Changes some of the old CP accesses to go via Admin instead. Added at least one call to Admin to compensate. More to do. Need to address Andrew comment above too > MasterServices - remove from coprocessor API (Discuss) > -- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12260: -- Status: Patch Available (was: Open) See what breaks. > MasterServices - remove from coprocessor API (Discuss) > -- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18924) Backport HBASE-18568 (Correct metric of numRegions) to branch-1.2 and branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193920#comment-16193920 ] Mike Drob commented on HBASE-18924: --- The patch applies to branch-1.2 but not branch-1.3 - I'll take a look and see what the conflict is in a moment. > Backport HBASE-18568 (Correct metric of numRegions) to branch-1.2 and > branch-1.3 > > > Key: HBASE-18924 > URL: https://issues.apache.org/jira/browse/HBASE-18924 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.6 >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Critical > Fix For: 1.3.2, 1.2.7 > > Attachments: HBASE-18924.branch-1.2.001.patch, > HBASE-18924.branch-1.2.002.patch > > > HBASE-18568 corrects an issue with metrics which leads to memory leak. We > should apply this fix to branch-1.2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-12260) MasterServices - remove from coprocessor API (Discuss)
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12260: -- Attachment: HBASE-12260.master.002.patch > MasterServices - remove from coprocessor API (Discuss) > -- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18601) Update Htrace to 4.2
[ https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated HBASE-18601: - Attachment: HBASE-18601.master.008.patch > Update Htrace to 4.2 > > > Key: HBASE-18601 > URL: https://issues.apache.org/jira/browse/HBASE-18601 > Project: HBase > Issue Type: Task >Affects Versions: 2.0.0, 3.0.0 >Reporter: Tamas Penzes >Assignee: Tamas Penzes > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18601.master.001.patch, > HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, > HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, > HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, > HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.008.patch > > > HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, > the upgrade to 4.x is not trivial and would take time. It might not worth to > keep it in this state, so would be better to remove it. > Of course it doesn't mean tracing would be useless, just that in this form > the use of HTrace 3.2 might not add any value to the project and fixing it > would be far too much effort. > - > Based on the decision of the community we keep htrace now and update version -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18601) Update Htrace to 4.2
[ https://issues.apache.org/jira/browse/HBASE-18601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193550#comment-16193550 ] Tamas Penzes edited comment on HBASE-18601 at 10/5/17 11:38 PM: new version uploaded, hopefully all NPEs eliminated was (Author: tamaas): another version is coming soon... > Update Htrace to 4.2 > > > Key: HBASE-18601 > URL: https://issues.apache.org/jira/browse/HBASE-18601 > Project: HBase > Issue Type: Task >Affects Versions: 2.0.0, 3.0.0 >Reporter: Tamas Penzes >Assignee: Tamas Penzes > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18601.master.001.patch, > HBASE-18601.master.002.patch, HBASE-18601.master.003 (3).patch, > HBASE-18601.master.003.patch, HBASE-18601.master.004.patch, > HBASE-18601.master.004.patch, HBASE-18601.master.005.patch, > HBASE-18601.master.006.patch, HBASE-18601.master.006.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.007.patch, > HBASE-18601.master.007.patch, HBASE-18601.master.008.patch > > > HTrace is not perfectly integrated into HBase, the version 3.2.0 is buggy, > the upgrade to 4.x is not trivial and would take time. It might not worth to > keep it in this state, so would be better to remove it. > Of course it doesn't mean tracing would be useless, just that in this form > the use of HTrace 3.2 might not add any value to the project and fixing it > would be far too much effort. > - > Based on the decision of the community we keep htrace now and update version -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18951) Use Builder pattern to remove nullable parameters in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193911#comment-16193911 ] Duo Zhang commented on HBASE-18951: --- Just like the Curator. zk.exists().path(xxx).execute() Or maybe called fluent API? > Use Builder pattern to remove nullable parameters in RawAsyncTable/AsyncTable > interface > --- > > Key: HBASE-18951 > URL: https://issues.apache.org/jira/browse/HBASE-18951 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > > As Optional is not supposed to be used as method parameters but we do not > want nullable parameters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18843) Add DistCp support to incremental backup with bulk loading
[
https://issues.apache.org/jira/browse/HBASE-18843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16192192#comment-16192192
]
Ted Yu edited comment on HBASE-18843 at 10/5/17 11:31 PM:
--
Building / installing 3.0.0-beta1 locally with HDFS-12599 and HADOOP-14930, I
was able to run TestIncrementalBackup with the following commands:
{code}
mvn clean install -DskipTests -Phadoop-3.0 -Dhadoop-three.version=3.0.0-beta1
-Dhadoop-two.version=3.0.0-beta1
mvn test -Dtest=TestIncrementalBackup -Phadoop-3.0
-Dhadoop-three.version=3.0.0-beta1 -Dhadoop-two.version=3.0.0-beta1
{code}
The test failed here (without Vlad's patch):
{code}
java.lang.NoSuchFieldException: inputOptions
at java.lang.Class.getDeclaredField(Class.java:2070)
at
org.apache.hadoop.hbase.backup.mapreduce.MapReduceBackupCopyJob$BackupDistCp.execute(MapReduceBackupCopyJob.java:168)
{code}
was (Author: yuzhih...@gmail.com):
Even though the above error can be reproduced on command line, every time I
debug in Eclipse, hadoop 2.7.1 is used:
{code}
2017-10-04 16:16:36,709 INFO [main] log.Slf4jLog(67): Extract
jar:file:/Users/tyu/.m2/repository/org/apache/hadoop/hadoop-hdfs/2.7.1/hadoop-hdfs-2.7.1-tests.jar!/webapps/datanode
to
/var/folders/4g/2vdss5497xx9blpn2pbqc38rgn/T/Jetty_localhost_55722_datanode.nq742/webapp
{code}
Still hunting for the cause.
> Add DistCp support to incremental backup with bulk loading
> --
>
> Key: HBASE-18843
> URL: https://issues.apache.org/jira/browse/HBASE-18843
> Project: HBase
> Issue Type: Improvement
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-18843-v1.patch, HBASE-18843-v2.patch,
> HBASE-18843-v4.patch, HBASE-18843-v5.patch, HBASE-18843-v6.patch,
> HBASE-18843-v7.patch
>
>
> Currently, we copy bulk loaded files to backup one-by-one on a client side
> (where backup create runs). This has to be replaced with DistCp copying.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18925) Need updated mockito for using java optional
[
https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193900#comment-16193900
]
Hadoop QA commented on HBASE-18925:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} 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 12 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
26s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
1s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 7m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 13m
12s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m
22s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
45s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
15s{color} | {color:red} hbase-rest in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
23s{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
15s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
40m 2s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-shaded/hbase-shaded-check-invariants . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m
57s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
37s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
27s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
12s{color} | {color:green} hbase-metrics-api in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
18s{color} | {color:green} hbase-metrics in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
45s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 87m 22s{col
[jira] [Updated] (HBASE-18924) Backport HBASE-18568 (Correct metric of numRegions) to branch-1.2 and branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18924: -- Fix Version/s: 1.3.2 > Backport HBASE-18568 (Correct metric of numRegions) to branch-1.2 and > branch-1.3 > > > Key: HBASE-18924 > URL: https://issues.apache.org/jira/browse/HBASE-18924 > Project: HBase > Issue Type: Bug > Components: metrics >Affects Versions: 1.2.6 >Reporter: Peter Somogyi >Assignee: Peter Somogyi >Priority: Critical > Fix For: 1.3.2, 1.2.7 > > Attachments: HBASE-18924.branch-1.2.001.patch, > HBASE-18924.branch-1.2.002.patch > > > HBASE-18568 corrects an issue with metrics which leads to memory leak. We > should apply this fix to branch-1.2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[ https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18108: -- Status: Patch Available (was: Open) > Procedure WALs are archived but not cleaned; fix > > > Key: HBASE-18108 > URL: https://issues.apache.org/jira/browse/HBASE-18108 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Peter Somogyi >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18108.master.001.patch > > > The Procedure WAL files used to be deleted when done. HBASE-14614 keeps them > around in case issue but what is missing is a GC for no-longer-needed WAL > files. This one is pretty important. > From WALProcedureStore Cleaner TODO in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.r2pc835nb7vi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[ https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18108: -- Attachment: HBASE-18108.master.001.patch > Procedure WALs are archived but not cleaned; fix > > > Key: HBASE-18108 > URL: https://issues.apache.org/jira/browse/HBASE-18108 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Peter Somogyi >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18108.master.001.patch > > > The Procedure WAL files used to be deleted when done. HBASE-14614 keeps them > around in case issue but what is missing is a GC for no-longer-needed WAL > files. This one is pretty important. > From WALProcedureStore Cleaner TODO in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.r2pc835nb7vi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[ https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18108: -- Attachment: (was: HBASE-18108.master.001.patch) > Procedure WALs are archived but not cleaned; fix > > > Key: HBASE-18108 > URL: https://issues.apache.org/jira/browse/HBASE-18108 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Peter Somogyi >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18108.master.001.patch > > > The Procedure WAL files used to be deleted when done. HBASE-14614 keeps them > around in case issue but what is missing is a GC for no-longer-needed WAL > files. This one is pretty important. > From WALProcedureStore Cleaner TODO in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.r2pc835nb7vi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18925) Need updated mockito for using java optional
[ https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18925: - Attachment: HBASE-18925.master.003.patch > Need updated mockito for using java optional > > > Key: HBASE-18925 > URL: https://issues.apache.org/jira/browse/HBASE-18925 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18925.master.001.patch, > HBASE-18925.master.002.patch, HBASE-18925.master.002.patch, > HBASE-18925.master.003.patch > > > Came up when i was trying to test HBASE-18878. > It kept failing because mock of RpcCall returned null where return type was > Optional. > Instead, we want it to return Optional.empty(). > New mockito versions support this (and other java8 things) - > https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2 > We use mockito-all which was last released in Dec2014. However, mockito-core > has had more than 50 releases after that > (https://mvnrepository.com/artifact/org.mockito/mockito-core). > We need to change our deps from mockito-all to mockito-core. > However that comes with fair breakages, so this is not a simple task of > changing pom files. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18108) Procedure WALs are archived but not cleaned; fix
[ https://issues.apache.org/jira/browse/HBASE-18108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18108: -- Attachment: HBASE-18108.master.001.patch > Procedure WALs are archived but not cleaned; fix > > > Key: HBASE-18108 > URL: https://issues.apache.org/jira/browse/HBASE-18108 > Project: HBase > Issue Type: Sub-task > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: stack >Assignee: Peter Somogyi >Priority: Blocker > Fix For: 2.0.0 > > Attachments: HBASE-18108.master.001.patch > > > The Procedure WAL files used to be deleted when done. HBASE-14614 keeps them > around in case issue but what is missing is a GC for no-longer-needed WAL > files. This one is pretty important. > From WALProcedureStore Cleaner TODO in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.r2pc835nb7vi -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18934) precommit on branch-1 isn't supposed to run against hadoop 3
[ https://issues.apache.org/jira/browse/HBASE-18934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey reassigned HBASE-18934: --- Assignee: Sean Busbey > precommit on branch-1 isn't supposed to run against hadoop 3 > > > Key: HBASE-18934 > URL: https://issues.apache.org/jira/browse/HBASE-18934 > Project: HBase > Issue Type: Bug > Components: test >Affects Versions: 1.5.0 >Reporter: Sean Busbey >Assignee: Sean Busbey >Priority: Critical > > Hadoop 3 doesn't work with HBase 1.y and we haven't done any work to backport > the efforts to make HBase 2.y work with it. Precommit shouldn't tell > contributors otherwise. > see HBASE-18923 for an example of a branch-1 patch that had hadoop 3 > compilation checked. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18925) Need updated mockito for using java optional
[ https://issues.apache.org/jira/browse/HBASE-18925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193878#comment-16193878 ] Appy commented on HBASE-18925: -- Next hadoop QA is going to be red. The failure in TestZKProcedureControllers was legit. Uploading new patch. Not sure about timed out tests though. Let see if they reappear again. > Need updated mockito for using java optional > > > Key: HBASE-18925 > URL: https://issues.apache.org/jira/browse/HBASE-18925 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18925.master.001.patch, > HBASE-18925.master.002.patch, HBASE-18925.master.002.patch > > > Came up when i was trying to test HBASE-18878. > It kept failing because mock of RpcCall returned null where return type was > Optional. > Instead, we want it to return Optional.empty(). > New mockito versions support this (and other java8 things) - > https://github.com/mockito/mockito/wiki/What%27s-new-in-Mockito-2 > We use mockito-all which was last released in Dec2014. However, mockito-core > has had more than 50 releases after that > (https://mvnrepository.com/artifact/org.mockito/mockito-core). > We need to change our deps from mockito-all to mockito-core. > However that comes with fair breakages, so this is not a simple task of > changing pom files. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193852#comment-16193852 ] Josh Elser commented on HBASE-18948: Yes... the patch needs fixing. I assumed that was clear from the discussion. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18931) Make ObserverContext an interface and remove private/testing methods
[ https://issues.apache.org/jira/browse/HBASE-18931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18931: - Attachment: HBASE-18931.master.003.patch > Make ObserverContext an interface and remove private/testing methods > > > Key: HBASE-18931 > URL: https://issues.apache.org/jira/browse/HBASE-18931 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18931.master.001.patch, > HBASE-18931.master.002.patch, HBASE-18931.master.003.patch > > > ObserverContext is IA.LimitedPrivate because CP implementations want > getEnvironment(), bypass(), etc. > We can split interface and implementations (suggested by [~Apache9]). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193837#comment-16193837 ] Vrushali C commented on HBASE-18948: Hmm I did read the discussion. I understood it as security coprocessors will strip out tags set by clients. But the proposed patch says, coprocessor code can not get/set tags, which is incorrect. Coprocessors run on RS as part of the server and are allowed to get/set cell Tags. They are stripped off before sending the cell back to client. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18955) HBase client queries stale hbase:meta location with half-dead RegionServer
Josh Elser created HBASE-18955:
--
Summary: HBase client queries stale hbase:meta location with
half-dead RegionServer
Key: HBASE-18955
URL: https://issues.apache.org/jira/browse/HBASE-18955
Project: HBase
Issue Type: Bug
Components: Client
Affects Versions: 1.1.12
Reporter: Josh Elser
Assignee: Josh Elser
Priority: Critical
Fix For: 1.1.13
Have been investigating a case with [~tedyu] where, when a RegionServer becomes
"hung" (for no specific reason -- not the point), the client becomes stuck
trying to talk to this RegionServer, never exiting. This was eventually tracked
down to HBASE-15645. However, in testing the fix, I found that there is an
additional problem which only affects branch-1.1.
When the RegionServer in the "half-dead" state is also hosting meta, the hbase
client (both the one trying to read data, but also the client in the Master
trying to read meta in SSH) get stuck repeatedly trying to read meta from the
old location after meta has been reassigned.
The general test outline goes like this:
* Start at least 2 regionservers
* Load some data into a table ({{hbase pe}} is great)
* Find a region that is hosted by the same RS that is hosting meta
* {{kill -SIGSTOP}} that RS hosting the user region and meta
* Issue a {{get}} in the hbase-shell trying to read from that user region
The expectation is that the ZK lock will expire for the STOP'ed RS, meta will
be reassigned, then the user regions will be reassigned, then the client will
get the result of the get without seeing an error (as long as this happens
within the hbase.client.operation.timeout value, of course).
We see this happening on HBase 1.2.4 and 1.3.2-SNAPSHOT, but, on
1.1.13-SNAPSHOT, the Master gets up to re-assigning meta, but then gets stuck
trying to read meta from the STOP'ed RS instead of where it re-assigned it.
Because of this, the regions stay in transition until the master is restarted
or the STOP'ed RS is CONT'ed. My best guess is that when the RS sees the
{{SIGCONT}}, it immediately begins stopping which is enough to kick the client
into refreshing the region location cache.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18947) HBase backups backup all tables once backed up irrespective of the table names passed to it.
[
https://issues.apache.org/jira/browse/HBASE-18947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-18947:
--
Resolution: Invalid
Status: Resolved (was: Patch Available)
I am closing this as invalid. This is by design: during incremental backup we
create backup images for ALL tables in HBase (because its free for us).
> HBase backups backup all tables once backed up irrespective of the table
> names passed to it.
> -
>
> Key: HBASE-18947
> URL: https://issues.apache.org/jira/browse/HBASE-18947
> Project: HBase
> Issue Type: Bug
>Reporter: Amit Kabra
>Assignee: Amit Kabra
> Attachments: HBASE-18947.patch
>
>
> Take backup of test1,test2,test3,test11,test12,test13
> and then take backup of only test2
> {code}./hbase backup -d create incremental hdfs://localhost:8020/test/ -t
> test2{code}
> It should only backup test2 but it backup all tables once backed up. This can
> be seen in hdfs as backed up tables and logs show the same :
> Logs show :
> 2017-09-25 19:29:39,170 DEBUG [main] impl.IncrementalTableBackupClient: For
> incremental backup, current table set is [test1,test2,test3,test11,
> test12,test13]
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18940) branch-2 (and probably others) fail check of generated source artifact
[
https://issues.apache.org/jira/browse/HBASE-18940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193824#comment-16193824
]
Hudson commented on HBASE-18940:
FAILURE: Integrated in Jenkins build HBase-2.0 #633 (See
[https://builds.apache.org/job/HBase-2.0/633/])
HBASE-18940 include project pylint configs in source artifact. (busbey: rev
b57c9bf400af8e1cbcc13820298c9235aac3a98a)
* (edit) hbase-assembly/src/main/assembly/src.xml
> branch-2 (and probably others) fail check of generated source artifact
> --
>
> Key: HBASE-18940
> URL: https://issues.apache.org/jira/browse/HBASE-18940
> Project: HBase
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0, 2.0.0-alpha-4
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Critical
> Labels: beginner
> Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13, 2.0.0-alpha-4
>
> Attachments: HBASE-18940.0.patch
>
>
> This shows up in branch-2 nightly:
> https://builds.apache.org/job/HBase%20Nightly/job/branch-2/62/console
> Pulling out the failure:
> {code}
> 00:06:59 Diff against source tree
> [Pipeline] }
> [Pipeline] // dir
> [Pipeline] sh
> 00:07:00
> [HBase_Nightly_branch-2-MO2I3RYUAQ2OT52Z2B54XSO6W34ZHP3JU2DA5UQYCAVNS747RZWQ]
> Running shell script
> 00:07:01 Checking against things we don't expect to include in the source
> tarball (git related, hbase-native-client, etc.)
> 00:07:01 Any output here are unexpected differences between the source
> artifact we'd make for an RC and the current branch.
> 00:07:01 The expected differences are on the < side and the current
> differences are on the > side.
> 00:07:01 In a given set of differences, '.' refers to the branch in the repo
> and 'unpacked_src_tarball' refers to what we pulled out of the tarball.
> 00:07:01 3a4
> 00:07:01 > Only in ./hbase-backup: .DS_Store
> 00:07:01 4a6
> 00:07:01 > Only in .: .pylintrc
> [Pipeline] }
> {code}
> Looks like this says the source checkout has two files we don't see in the
> source tarball. {{.DS_Store}} looks like a bad commit from someone on a Mac
> and {{.plyintrc}} is an old oversight, should probably be included in the
> source artifact.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193800#comment-16193800 ] Josh Elser commented on HBASE-18948: bq. But coprocessors can currently access and set cell Tags. So then the proposed patch is not accurate. bq. Edit: I know the security coprocessors defend against the possibility of user submission of faked security cell tag by stripping them out. Or, I remember writing that code. Again the current state of the code should be reviewed. Please see the discussion already on this issue that recommended that the code must be reviewed to ensure that all CP paths are accurate. There is ambiguity around this area. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193764#comment-16193764 ] Josh Elser commented on HBASE-18948: [~vrushalic], no. This is trying to update the documentation to accurately reflect the current state of what is and is not possible WRT tags. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193789#comment-16193789 ] Vrushali C commented on HBASE-18948: But coprocessors can currently access and set cell Tags. So then the proposed patch is not accurate. > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-17892) Hierarchical paths for WALs
[ https://issues.apache.org/jira/browse/HBASE-17892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashu Pachauri resolved HBASE-17892. --- Resolution: Duplicate Closing this as duplicate because HBASE-14247 is actively being worked on which solves the same issue. > Hierarchical paths for WALs > --- > > Key: HBASE-17892 > URL: https://issues.apache.org/jira/browse/HBASE-17892 > Project: HBase > Issue Type: Improvement > Components: Replication, wal >Reporter: Ashu Pachauri > > Currently all WALs are just dumped into a single directory irrespective of > the ServerName for the regionserver to which they belong. > This is a problem specifically for the WALs archive directory > (HConstants.HREGION_OLDLOGDIR_NAME) since it holds a large number of files > which can easily make it go above the HDFS max items in a directory limit for > large clusters in scenarios like pausing replication. HDFS imposes a hard > limit of around 6 million files in a single directory due to Protobuf > serialization limitations. > We should put WALs for a particular servername in its own directory inside > the WALs (archive) directory. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18948) HBase tags are server side only.
[ https://issues.apache.org/jira/browse/HBASE-18948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193758#comment-16193758 ] Vrushali C commented on HBASE-18948: IIUC coprocessors will not be able to get/set Tags in HBase 3.0, is that what is being said here? > HBase tags are server side only. > > > Key: HBASE-18948 > URL: https://issues.apache.org/jira/browse/HBASE-18948 > Project: HBase > Issue Type: Improvement > Components: documentation >Reporter: Thiriguna Bharat Rao >Assignee: Thiriguna Bharat Rao >Priority: Minor > Fix For: 3.0.0 > > Attachments: HBASE-18948.patch > > > HBase tags are server side only. In the Apache HBase documentation, in > section 62.1.1 http://hbase.apache.org/book.html#_implementation_details , I > am going to add a sentence to state explicitly that "Tags are not available > for get/set from client operations including coprocessors". -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18953) Use hadoop shaded jars for hadoop-3 profile
[
https://issues.apache.org/jira/browse/HBASE-18953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193756#comment-16193756
]
Sean Busbey commented on HBASE-18953:
-
Copying my comment from HADOOP-14178:
{quote}
Maybe in the future? Right now HBase's dependency on Hadoop is kind of messy
for a few reasons.
# we have to keep working on top of Hadoop 2.x and Hadoop 3.x. We mostly have
this abstracted.
# we have parts of HBase that make use of Hadoop internals such that we can't
currently move all of the Hadoop-3 build version on to the client artifacts
# The parts of HBase that use Hadoop internals are currently all mixed up with
parts that are proper downstream consumers, so we can't even e.g. isolate the
problem parts and then avoid mockito there.
{quote}
The hadoop client artifacts have to be used to the exclusion of the
non-downstream facing ones. you can't leave in e.g. hadoop-common. I have a
branch sitting around somewhere from the last time I tried to do this via
either moving our internal Hadoop usage to different modules or copying source
into our tree. It was a morass, but things are considerably better now in our
codebase.
If you're interested in digging into this [~tedyu], I'd be willing to rebase my
prior attempt and note where it looks broken to give you a starting point. Fair
warning though, it's probably still a good deal of work.
> Use hadoop shaded jars for hadoop-3 profile
> ---
>
> Key: HBASE-18953
> URL: https://issues.apache.org/jira/browse/HBASE-18953
> Project: HBase
> Issue Type: Improvement
>Reporter: Ted Yu
> Attachments: 18953.v1.txt
>
>
> Over HADOOP-14178 , [~bharatviswa] suggested using hadoop shaded jars for
> hadoop-3 since Hadoop client run time has all 3rd party dependencies of
> Hadoop.
> This would avoid issues starting mini dfs cluster.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193736#comment-16193736 ] Mike Drob commented on HBASE-16338: --- Dropping the JSON annotation seems to have worked, I'll go with that in my next patch. Currently trying to debug why CellSetModelStream.Row isn't getting populated in TableScanResource. > update jackson to 2.y > - > > Key: HBASE-16338 > URL: https://issues.apache.org/jira/browse/HBASE-16338 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Sean Busbey >Assignee: Mike Drob > Fix For: 2.0.0-beta-2 > > Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch > > > Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line, > using 2.7.0+. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193708#comment-16193708
]
Sean Busbey commented on HBASE-16338:
-
does this work?
{code}
@JsonProperty(value="$")
@XmlValue
private byte[] value;
{code}
> update jackson to 2.y
> -
>
> Key: HBASE-16338
> URL: https://issues.apache.org/jira/browse/HBASE-16338
> Project: HBase
> Issue Type: Task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch
>
>
> Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line,
> using 2.7.0+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17961) Allow passing cluster specific configs to the integration test replication
[ https://issues.apache.org/jira/browse/HBASE-17961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashu Pachauri updated HBASE-17961: -- Component/s: integration tests > Allow passing cluster specific configs to the integration test replication > -- > > Key: HBASE-17961 > URL: https://issues.apache.org/jira/browse/HBASE-17961 > Project: HBase > Issue Type: Improvement > Components: integration tests >Reporter: Ashu Pachauri > > Currently, ITR takes only the cluster key as input, which is insufficient to > set it up for certain scenarios. > One common scenario is when one of the clusters have kerberos security > enabled, in which case, the kerberos credentials needed to authenticate on > the source differ from that on the destination. > We should be able to pass cluster specific config to ITR. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193682#comment-16193682 ] Sean Busbey commented on HBASE-16338: - is it possible we're just using the JsonProperty annotation wrong and all of the other fields were defaulting to their name (which looks to match) and since the '$' one differs it flagged as bad? > update jackson to 2.y > - > > Key: HBASE-16338 > URL: https://issues.apache.org/jira/browse/HBASE-16338 > Project: HBase > Issue Type: Task > Components: dependencies >Reporter: Sean Busbey >Assignee: Mike Drob > Fix For: 2.0.0-beta-2 > > Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch > > > Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line, > using 2.7.0+. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-16338) update jackson to 2.y
[
https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16193676#comment-16193676
]
Sean Busbey commented on HBASE-16338:
-
Jackson 2.x docs say that {{JsonProperty}} without a name will use the name of
the field. So we should be able to simplify CellModel (even for other fields
without changing compatibility)
> update jackson to 2.y
> -
>
> Key: HBASE-16338
> URL: https://issues.apache.org/jira/browse/HBASE-16338
> Project: HBase
> Issue Type: Task
> Components: dependencies
>Reporter: Sean Busbey
>Assignee: Mike Drob
> Fix For: 2.0.0-beta-2
>
> Attachments: 16338.txt, HBASE-16338.v2.patch, HBASE-16338.v3.patch
>
>
> Our jackson dependency is from ~3 years ago. Update to the jackson 2.y line,
> using 2.7.0+.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
