[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=16198278#comment-16198278 ] ramkrishna.s.vasudevan commented on HBASE-18946: I now got the real issue why this happens. Need to check in other branches which is not PRocV2. Suppose we create a table with 20 regions and say replica as 3. Now we create 60 Assign procedures. Now all these assign procedures are added to a queue 'pendingAssignQueue' in AM. There is a thread that executes the assignment of the regions in this queue. So when ever all the 60 regions are added to this queue and the assignment thread assigns them we have no problem. The Stochastic LB uses the replica concept to ensure the regions are assigned properly. The Cluster and Cost functions created per 'roundRobinAssignment' ensures that happens. But when the multi threaded model executes differently like the 60 regions are executed with 45 and 15 regions each then we end up in this issue every time. Because the roundRobinAssignment Cluster creation is not global and it is per assignment. > 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=16198281#comment-16198281 ] ramkrishna.s.vasudevan commented on HBASE-18946: One way to fix is that for CreateTableProcedure atleast we should not split the assignments - we should ensure that all the regions are added as a unit and the assignment should proceed. > 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] [Updated] (HBASE-18951) Use Builder pattern to remove nullable parameters for checkAndXXX methods in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18951: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: (was: 2.0.0-beta-1) 2.0.0-alpha-4 Status: Resolved (was: Patch Available) Pushed to master and branch-2. Thanks all for reviewing. > Use Builder pattern to remove nullable parameters for checkAndXXX methods 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-alpha-4 > > Attachments: HBASE-18951-v1.patch, HBASE-18951.patch > > > 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] [Commented] (HBASE-18951) Use Builder pattern to remove nullable parameters for checkAndXXX methods in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198282#comment-16198282 ] Duo Zhang commented on HBASE-18951: --- Filed HBASE-18978. > Use Builder pattern to remove nullable parameters for checkAndXXX methods 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-alpha-4 > > Attachments: HBASE-18951-v1.patch, HBASE-18951.patch > > > 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] [Created] (HBASE-18978) Align the methods in Table and AsyncTable
Duo Zhang created HBASE-18978: - Summary: Align the methods in Table and AsyncTable Key: HBASE-18978 URL: https://issues.apache.org/jira/browse/HBASE-18978 Project: HBase Issue Type: Task Components: asyncclient, Client Reporter: Duo Zhang Priority: Critical Fix For: 2.0.0-beta-1 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198302#comment-16198302 ] Zheng Hu commented on HBASE-18410: -- Well,It's quite an adjustment for me when I wake up from my vocation. My original plan is: fix HBASE-17678 first , then HBASE-18160 (after resolved it, HBASE-18414 & HBASE-18416 will be resolved automatically), Because of the uniformity solution for HBASE-18368, so I try to solve it in the end. Seems like 2.0.0-alpha-4 can not wait until all this issues to be resolved. Well, It's OK for me to put all this fix into an individual branch which is named HBASE-18410. But I have one question: because of the difference for each branch, and our branch HBASE-18410 will works fine for master & branch-2 when merging them, but how about branch-1.x , merging HBASE-18410 with branch-1.x will lead to many conflicts , need a new feature branch for branch-1.x ? [~busbey] > FilterList Improvement. > - > > Key: HBASE-18410 > URL: https://issues.apache.org/jira/browse/HBASE-18410 > Project: HBase > Issue Type: Umbrella > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > > FilterList.java is complex now, and we have found some improvements for it. > So create an issue to address it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18957) add test that confirms 2 FamilyFilters in a FilterList using MUST_PASS_ONE operator will return results that match either of the FamilyFilters and revert as needed to
[ https://issues.apache.org/jira/browse/HBASE-18957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198303#comment-16198303 ] Zheng Hu commented on HBASE-18957: -- Thanks for pinging me, I'm OK for the patches. > add test that confirms 2 FamilyFilters in a FilterList using MUST_PASS_ONE > operator will return results that match either of the FamilyFilters and > revert as needed to make it pass. > > > Key: HBASE-18957 > URL: https://issues.apache.org/jira/browse/HBASE-18957 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Sean Busbey >Assignee: Peter Somogyi >Priority: Critical > 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-18957-branch-1.2.v0.patch, > HBASE-18957-branch-1.2.v1.patch, HBASE-18957-branch-1.4.v1.patch, > HBASE-18957-branch-1.v1.patch, HBASE-18957-master.v1.patch > > > we need a test that shows the expected behavior for filter lists that rely on > OR prior to our filterlist improvements so we have a baseline to show > compatibility (and/or document incompatibilities that end up being > introduced). > Specifically (paraphrased from HBASE-18368 description): Using 2 > FamilyFilters in a FilterList using MUST_PASS_ONE operator should return > results that match either of the FamilyFilters. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18879) Hbase FilterList cause KeyOnlyFilter not work
[
https://issues.apache.org/jira/browse/HBASE-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zheng Hu updated HBASE-18879:
-
Issue Type: Sub-task (was: Bug)
Parent: HBASE-18410
> Hbase FilterList cause KeyOnlyFilter not work
> -
>
> Key: HBASE-18879
> URL: https://issues.apache.org/jira/browse/HBASE-18879
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 1.2.4
> Environment: OS： Red Hat 4.4.7-11
> Hadoop: 2.6.4
> Hbase: 1.2.4
>Reporter: ZHA_Moonlight
>
> when use FilterList and KeyOnlyFilter together, if we put KeyOnlyFilter
> before FilterList, the KeyOnlyFilter may not work, means it will also grab
> the cell values:
> {code:java}
> List filters = new ArrayList();
> Filter filter1 = new SingleColumnValueFilter(Bytes.toBytes("cf"),
> Bytes.toBytes("column1"),
> CompareOp.EQUAL, Bytes.toBytes("value1"));
> Filter filter2 = new SingleColumnValueFilter(Bytes.toBytes("cf"),
> Bytes.toBytes("column1"),
> CompareOp.EQUAL, Bytes.toBytes("value2"));
> filters.add(filter1);
> filters.add(filter2);
> FilterList filterListAll = new FilterList(Operator.MUST_PASS_ALL,
> new KeyOnlyFilter(),
> new FilterList(Operator.MUST_PASS_ONE, filters));
> {code}
> use the above code as filter to scan a table, it will return the cells with
> value instead of only return the key, if we put KeyOnlyFilter after
> FilterList as following, it works well.
>
> {code:java}
> FilterList filterListAll = new FilterList(Operator.MUST_PASS_ALL,
> new FilterList(Operator.MUST_PASS_ONE, filters),
> new KeyOnlyFilter());
> {code}
> the cause should due to the following code at hbase-client FilterList.java
> {code:java}
> @Override
>
> @edu.umd.cs.findbugs.annotations.SuppressWarnings(value="SF_SWITCH_FALLTHROUGH",
> justification="Intentional")
> public ReturnCode filterKeyValue(Cell v) throws IOException {
> this.referenceKV = v;
> // Accumulates successive transformation of every filter that includes
> the Cell:
> Cell transformed = v;
> ReturnCode rc = operator == Operator.MUST_PASS_ONE?
> ReturnCode.SKIP: ReturnCode.INCLUDE;
> int listize = filters.size();
> for (int i = 0; i < listize; i++) {
> Filter filter = filters.get(i);
> if (operator == Operator.MUST_PASS_ALL) {
> if (filter.filterAllRemaining()) {
> return ReturnCode.NEXT_ROW;
> }
> LINE1 ReturnCode code = filter.filterKeyValue(v);{color}
> switch (code) {
> // Override INCLUDE and continue to evaluate.
> case INCLUDE_AND_NEXT_COL:
> rc = ReturnCode.INCLUDE_AND_NEXT_COL; // FindBugs
> SF_SWITCH_FALLTHROUGH
> case INCLUDE:
> LINE2 transformed = filter.transformCell(transformed);{color}
>
> continue;
> case SEEK_NEXT_USING_HINT:
> seekHintFilter = filter;
> return code;
> default:
> return code;
> }
> }
> {code}
> notice the “LINE1”,"LINE2" , first line is a recursive invocation, it will
> assign a Cell results to the FilterList.transformedKV(we call it A), the
> results is from the FilterList with 2 SingleColumnValueFilter, so A with
> contains the cell value, while the second line with return A to the var
> transformed.
> back to the following loop, we can see the FilterList return results is var
> "transformed " which will override in each loop, so the value is determined
> by the last filter, so the order of KeyOnlyFilter will impact the results.
> {code:java}
> Cell transformed = v;
> ReturnCode rc = operator == Operator.MUST_PASS_ONE?
> ReturnCode.SKIP: ReturnCode.INCLUDE;
> int listize = filters.size();
> for (int i = 0; i < listize; i++) {
> Filter filter = filters.get(i);
> if (operator == Operator.MUST_PASS_ALL) {
> if (filter.filterAllRemaining()) {
> return ReturnCode.NEXT_ROW;
> }
> ReturnCode code = filter.filterKeyValue(v);
> switch (code) {
> // Override INCLUDE and continue to evaluate.
> case INCLUDE_AND_NEXT_COL:
> rc = ReturnCode.INCLUDE_AND_NEXT_COL; // FindBugs
> SF_SWITCH_FALLTHROUGH
> case INCLUDE:
> transformed = filter.transformCell(transformed);
> continue;
> case SEEK_NEXT_USING_HINT:
> seekHintFilter = filter;
> return code;
> default:
> return code;
> }
>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18350) RSGroups are broken under AMv2
[ https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Meszaros updated HBASE-18350: Attachment: HBASE-18350.master.001.patch > RSGroups are broken under AMv2 > -- > > Key: HBASE-18350 > URL: https://issues.apache.org/jira/browse/HBASE-18350 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: Balazs Meszaros >Priority: Blocker > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-18350.master.001.patch > > > The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what > offline is. > - Disabled/Ignore TestRSGroups. > This JIRA tracks the work to enable them (or remove/modify if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18350) RSGroups are broken under AMv2
[ https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Balazs Meszaros updated HBASE-18350: Status: Patch Available (was: Open) > RSGroups are broken under AMv2 > -- > > Key: HBASE-18350 > URL: https://issues.apache.org/jira/browse/HBASE-18350 > Project: HBase > Issue Type: Bug > Components: rsgroup >Affects Versions: 2.0.0-alpha-1 >Reporter: Stephen Yuan Jiang >Assignee: Balazs Meszaros >Priority: Blocker > Fix For: 2.0.0-beta-2 > > Attachments: HBASE-18350.master.001.patch > > > The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614: > - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what > offline is. > - Disabled/Ignore TestRSGroups. > This JIRA tracks the work to enable them (or remove/modify if not applicable). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18951) Use Builder pattern to remove nullable parameters for checkAndXXX methods in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18951: -- Component/s: asyncclient > Use Builder pattern to remove nullable parameters for checkAndXXX methods in > RawAsyncTable/AsyncTable interface > --- > > Key: HBASE-18951 > URL: https://issues.apache.org/jira/browse/HBASE-18951 > Project: HBase > Issue Type: Sub-task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18951-v1.patch, HBASE-18951.patch > > > 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] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198332#comment-16198332
]
Hadoop QA commented on HBASE-15631:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
17s{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 17 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
18s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m
20s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
16s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
22s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 15m
10s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
19s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
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: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m
20s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
55s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
10s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
12s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
1s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
3s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
3s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
17s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 3m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 16m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
15s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
25s{color} | {color:red} The patch generated 81 new + 272 unchanged - 2 fixed =
353 total (was 274) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
10s{color} | {color:red} The patch generated 77 new + 114 unchanged - 0 fixed =
191 total (was 114) {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m
0s{color} | {color:red} The patch has 123 line(s) that end in whitespace. Use
git apply --whitespace=fix <>. Refer
https://git-scm.com/docs/git-apply {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
10s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
23m 58s{color}
[jira] [Updated] (HBASE-18602) rsgroup cleanup unassign code
[
https://issues.apache.org/jira/browse/HBASE-18602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wang, Xinglong updated HBASE-18602:
---
Affects Version/s: (was: 2.0.0-alpha-1)
> rsgroup cleanup unassign code
> -
>
> Key: HBASE-18602
> URL: https://issues.apache.org/jira/browse/HBASE-18602
> Project: HBase
> Issue Type: Improvement
> Components: rsgroup
>Reporter: Wang, Xinglong
>Priority: Minor
> Attachments: HBASE-18602-master-v1.patch
>
>
> While walking through rsgroup code, I found that variable misplacedRegions
> has never been added any element into. This makes the unassign region code is
> not functional. And according to my test, it is actually unnecessary to do
> that.
> RSGroupBasedLoadBalancer.java
> {code:java}
> private Map> correctAssignments(
>Map> existingAssignments)
> throws HBaseIOException{
> Map> correctAssignments = new TreeMap<>();
> List misplacedRegions = new LinkedList<>();
> correctAssignments.put(LoadBalancer.BOGUS_SERVER_NAME, new
> LinkedList<>());
> for (Map.Entry> assignments :
> existingAssignments.entrySet()){
> ServerName sName = assignments.getKey();
> correctAssignments.put(sName, new LinkedList<>());
> List regions = assignments.getValue();
> for (HRegionInfo region : regions) {
> RSGroupInfo info = null;
> try {
> info = rsGroupInfoManager.getRSGroup(
> rsGroupInfoManager.getRSGroupOfTable(region.getTable()));
> } catch (IOException exp) {
> LOG.debug("RSGroup information null for region of table " +
> region.getTable(),
> exp);
> }
> if ((info == null) || (!info.containsServer(sName.getAddress( {
> correctAssignments.get(LoadBalancer.BOGUS_SERVER_NAME).add(region);
> } else {
> correctAssignments.get(sName).add(region);
> }
> }
> }
> //TODO bulk unassign?
> //unassign misplaced regions, so that they are assigned to correct groups.
> for(HRegionInfo info: misplacedRegions) {
> try {
> this.masterServices.getAssignmentManager().unassign(info);
> } catch (IOException e) {
> throw new HBaseIOException(e);
> }
> }
> return correctAssignments;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18867) maven enforcer plugin needs update to work with jdk9
[
https://issues.apache.org/jira/browse/HBASE-18867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198348#comment-16198348
]
Hudson commented on HBASE-18867:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #3860 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3860/])
HBASE-18867 update maven enforcer plugin. (mdrob: rev
54da4405d7c3f180df92d7ce70b0a1899eb69d19)
* (edit) pom.xml
> maven enforcer plugin needs update to work with jdk9
>
>
> Key: HBASE-18867
> URL: https://issues.apache.org/jira/browse/HBASE-18867
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13
>
> Attachments: HBASE-18867.0.patch, HBASE-18867.branch-1.3.patch,
> HBASE-18867.branch-1.patch
>
>
> build fails under jdk9, even when targeting java 8
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce
> (min-maven-min-java-banned-xerces) on project hbase: Execution
> min-maven-min-java-banned-xerces of goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce:
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4/maven-enforcer-plugin-1.4.jar
> [ERROR] urls[1] =
> file:/Users/busbey/.m2/repository/org/codehaus/mojo/extra-enforcer-rules/1.0-beta-6/extra-enforcer-rules-1.0-beta-6.jar
> [ERROR] urls[2] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[3] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[4] =
> file:/Users/busbey/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[5] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[6] =
> file:/Users/busbey/.m2/repository/com/ibm/icu/icu4j/56.1/icu4j-56.1.jar
> [ERROR] urls[7] =
> file:/Users/busbey/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[8] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[9] =
> file:/Users/busbey/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[10] =
> file:/Users/busbey/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[11] =
> file:/Users/busbey/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[12] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[13] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[14] =
> file:/Users/busbey/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[15] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[16] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[17] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[18] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[19] =
> file:/Users/busbey/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[20] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4/enforcer-api-1.4.jar
> [ERROR] urls[21] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4/enforcer-rules-1.4.jar
> [ERROR] urls[22] =
> file:/Users/busbey/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[23] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[24] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harne
[jira] [Commented] (HBASE-18949) Remove the CompactionRequest parameter in preCompactSelection
[
https://issues.apache.org/jira/browse/HBASE-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198349#comment-16198349
]
Hudson commented on HBASE-18949:
SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #3860 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3860/])
HBASE-18949 Remove the CompactionRequest parameter in (zhangduo: rev
c3b3fd7b8fd51f0dd1864a8cb618f88be16a)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/mob/compactions/TestMobCompactor.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
> Remove the CompactionRequest parameter in preCompactSelection
> -
>
> Key: HBASE-18949
> URL: https://issues.apache.org/jira/browse/HBASE-18949
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-18949.patch, HBASE-18949.patch
>
>
> As we do not have a CompactionRequest yet when pre compaction selection so we
> always pass a null when calling which is useless...
> {code}
> override = getCoprocessorHost().preCompactSelection(this,
> candidatesForCoproc,
> tracker, null, user);
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18972) Use Builder pattern to remove nullable parameters for coprocessor methods in RawAsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18972: -- Assignee: Duo Zhang Status: Patch Available (was: Open) > Use Builder pattern to remove nullable parameters for coprocessor methods in > RawAsyncTable interface > > > Key: HBASE-18972 > URL: https://issues.apache.org/jira/browse/HBASE-18972 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18972.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18972) Use Builder pattern to remove nullable parameters for coprocessor methods in RawAsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18972: -- Attachment: HBASE-18972.patch > Use Builder pattern to remove nullable parameters for coprocessor methods in > RawAsyncTable interface > > > Key: HBASE-18972 > URL: https://issues.apache.org/jira/browse/HBASE-18972 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18972.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18969) access hbase thrift2 in python and cant get correct result use filterString
[
https://issues.apache.org/jira/browse/HBASE-18969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198378#comment-16198378
]
bingo commented on HBASE-18969:
---
hbase(main):003:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{3}\\Q\x59\xc4\x98\\E.{1}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
\x00\x00\x03Y\xC4\x98\xD0\x00\x00\x0A\x00\x0 column=t:[\xC0\x8C1,
timestamp=1507530755374, value={\x00\xE1\x00
0\x05
1 row(s) in 0.0400 seconds
hbase(main):004:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{7}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
0 row(s) in 0.0140 seconds
The second one doesn't match?
> access hbase thrift2 in python and cant get correct result use filterString
> -
>
> Key: HBASE-18969
> URL: https://issues.apache.org/jira/browse/HBASE-18969
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Affects Versions: 1.1.2
> Environment: python 2.7
>Reporter: bingo
>
> {code}RowFilter(=,
> 'regexstring:(?s)^.{4}\\Q\xc4\x98\\E.{1}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$'){code}
> can match
> {code}\x00\x00\x03Y\xC4\x98\xD0\x00\x00\x0A\x00\x00\x05 column=t:[\xC0\x8C1,
> timestamp=1507530755374, value={\x00\xE1\x00 {code}
> but
> {code}RowFilter(=,
> 'regexstring:(?s)^.{4}\\Q\xc4\\E.{2}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$'){code}
> can not match
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18969) access hbase thrift2 in python and cant get correct result use filterString
[
https://issues.apache.org/jira/browse/HBASE-18969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198378#comment-16198378
]
bingo edited comment on HBASE-18969 at 10/10/17 8:59 AM:
-
{code}hbase(main):003:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{3}\\Q\x59\xc4\x98\\E.{1}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
\x00\x00\x03Y\xC4\x98\xD0\x00\x00\x0A\x00\x0 column=t:[\xC0\x8C1,
timestamp=1507530755374, value={\x00\xE1\x00
0\x05
1 row(s) in 0.0400 seconds
hbase(main):004:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{7}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
0 row(s) in 0.0140 seconds{code}
The second one doesn't match?
was (Author: hu198021688500):
hbase(main):003:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{3}\\Q\x59\xc4\x98\\E.{1}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
\x00\x00\x03Y\xC4\x98\xD0\x00\x00\x0A\x00\x0 column=t:[\xC0\x8C1,
timestamp=1507530755374, value={\x00\xE1\x00
0\x05
1 row(s) in 0.0400 seconds
hbase(main):004:0> scan 'wishdb1', {FILTER=>"RowFilter(=,
'regexstring:(?s)^.{7}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$')"}
ROW COLUMN+CELL
0 row(s) in 0.0140 seconds
The second one doesn't match?
> access hbase thrift2 in python and cant get correct result use filterString
> -
>
> Key: HBASE-18969
> URL: https://issues.apache.org/jira/browse/HBASE-18969
> Project: HBase
> Issue Type: Bug
> Components: Thrift
>Affects Versions: 1.1.2
> Environment: python 2.7
>Reporter: bingo
>
> {code}RowFilter(=,
> 'regexstring:(?s)^.{4}\\Q\xc4\x98\\E.{1}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$'){code}
> can match
> {code}\x00\x00\x03Y\xC4\x98\xD0\x00\x00\x0A\x00\x00\x05 column=t:[\xC0\x8C1,
> timestamp=1507530755374, value={\x00\xE1\x00 {code}
> but
> {code}RowFilter(=,
> 'regexstring:(?s)^.{4}\\Q\xc4\\E.{2}(?:.{6})*\\Q\x00\x00\x0a\x00\x00\x05\\E(?:.{6})*$'){code}
> can not match
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18867) maven enforcer plugin needs update to work with jdk9
[
https://issues.apache.org/jira/browse/HBASE-18867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198398#comment-16198398
]
Hudson commented on HBASE-18867:
SUCCESS: Integrated in Jenkins build HBase-2.0 #659 (See
[https://builds.apache.org/job/HBase-2.0/659/])
HBASE-18867 update maven enforcer plugin. (mdrob: rev
ca62f769b603514e97226d80d5306c5d067541a6)
* (edit) pom.xml
> maven enforcer plugin needs update to work with jdk9
>
>
> Key: HBASE-18867
> URL: https://issues.apache.org/jira/browse/HBASE-18867
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13
>
> Attachments: HBASE-18867.0.patch, HBASE-18867.branch-1.3.patch,
> HBASE-18867.branch-1.patch
>
>
> build fails under jdk9, even when targeting java 8
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce
> (min-maven-min-java-banned-xerces) on project hbase: Execution
> min-maven-min-java-banned-xerces of goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce:
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4/maven-enforcer-plugin-1.4.jar
> [ERROR] urls[1] =
> file:/Users/busbey/.m2/repository/org/codehaus/mojo/extra-enforcer-rules/1.0-beta-6/extra-enforcer-rules-1.0-beta-6.jar
> [ERROR] urls[2] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[3] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[4] =
> file:/Users/busbey/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[5] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[6] =
> file:/Users/busbey/.m2/repository/com/ibm/icu/icu4j/56.1/icu4j-56.1.jar
> [ERROR] urls[7] =
> file:/Users/busbey/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[8] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[9] =
> file:/Users/busbey/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[10] =
> file:/Users/busbey/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[11] =
> file:/Users/busbey/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[12] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[13] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[14] =
> file:/Users/busbey/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[15] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[16] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[17] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[18] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[19] =
> file:/Users/busbey/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[20] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4/enforcer-api-1.4.jar
> [ERROR] urls[21] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4/enforcer-rules-1.4.jar
> [ERROR] urls[22] =
> file:/Users/busbey/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[23] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[24] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-
[jira] [Updated] (HBASE-18972) Use Builder pattern to remove nullable parameters for coprocessor methods in RawAsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18972: -- Attachment: HBASE-18972-v1.patch Fix javadoc warnings. > Use Builder pattern to remove nullable parameters for coprocessor methods in > RawAsyncTable interface > > > Key: HBASE-18972 > URL: https://issues.apache.org/jira/browse/HBASE-18972 > Project: HBase > Issue Type: Sub-task > Components: Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-18972-v1.patch, HBASE-18972.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18972) Use Builder pattern to remove nullable parameters for coprocessor methods in RawAsyncTable interface
[
https://issues.apache.org/jira/browse/HBASE-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198418#comment-16198418
]
Hadoop QA commented on HBASE-18972:
---
| (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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{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} 0m
38s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s{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
14s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
21s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
27s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
38s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{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} 3m
59s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 26s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
18s{color} | {color:red} hbase-client generated 1 new + 2 unchanged - 0 fixed =
3 total (was 2) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
35s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
30s{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
14s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 59m 7s{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-18972 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891219/HBASE-18972.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 0fd144e472c9 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality
[jira] [Commented] (HBASE-15631) Backport Regionserver Groups (HBASE-6721) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-15631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198470#comment-16198470
]
Hadoop QA commented on HBASE-15631:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 18m
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 17 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
21s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
4s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
34s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
31s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 28m
58s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
20s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
58s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color}
|
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 10m
49s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
26s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
51s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
8s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m
8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
21s{color} | {color:green} hbase-protocol in the patch passed with JDK
v1.8.0_144. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
15s{color} | {color:green} hbase-common-jdk1.8.0_144 with JDK v1.8.0_144
generated 0 new + 18 unchanged - 18 fixed = 18 total (was 36) {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} hbase-client in the patch passed with JDK
v1.8.0_144. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
39s{color} | {color:green} hbase-server-jdk1.8.0_144 with JDK v1.8.0_144
generated 0 new + 5 unchanged - 5 fixed = 5 total (was 10) {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
15s{color} | {color:green} hbase-rsgroup in the patch passed with JDK
v1.8.0_144. {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
13s{color} | {color:green} hbase-shell in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
12s{color} | {color:green} hbase-shell in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
16s{color} | {color:green} hbase-it in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
40s{color} | {color:green} root in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
14s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 4m
14s{color} |
[jira] [Commented] (HBASE-18972) Use Builder pattern to remove nullable parameters for coprocessor methods in RawAsyncTable interface
[
https://issues.apache.org/jira/browse/HBASE-18972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198510#comment-16198510
]
Hadoop QA commented on HBASE-18972:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
16s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color: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
42s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
35s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
50s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
26s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 5m
15s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
40s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
24s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
30s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
13s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 16s{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
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
41s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
46s{color} | {color:green} hbase-endpoint in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
16s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 64m 14s{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-18972 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891231/HBASE-18972-v1.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 611013fe496c 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/Pr
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198527#comment-16198527
]
Hadoop QA commented on HBASE-18350:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 2 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
45s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
3s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
16s{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
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
20s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
20s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
51s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
45s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
4s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} rubocop {color} | {color:red} 0m
11s{color} | {color:red} The patch generated 11 new + 13 unchanged - 4 fixed =
24 total (was 17) {color} |
| {color:red}-1{color} | {color:red} ruby-lint {color} | {color:red} 0m
4s{color} | {color:red} The patch generated 7 new + 25 unchanged - 2 fixed = 32
total (was 27) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{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 29s{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
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
41s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}107m 5s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
40s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m
6s{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
54s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}194m 12s{color} |
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.
[jira] [Commented] (HBASE-18951) Use Builder pattern to remove nullable parameters for checkAndXXX methods in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198537#comment-16198537 ] Hudson commented on HBASE-18951: FAILURE: Integrated in Jenkins build HBase-2.0 #660 (See [https://builds.apache.org/job/HBase-2.0/660/]) HBASE-18951 Use Builder pattern to remove nullable parameters for (zhangduo: rev d5b76547f088783041212df559bcb08b6c641776) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableBase.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/RawAsyncTableImpl.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableImpl.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java > Use Builder pattern to remove nullable parameters for checkAndXXX methods in > RawAsyncTable/AsyncTable interface > --- > > Key: HBASE-18951 > URL: https://issues.apache.org/jira/browse/HBASE-18951 > Project: HBase > Issue Type: Sub-task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18951-v1.patch, HBASE-18951.patch > > > 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] [Commented] (HBASE-18949) Remove the CompactionRequest parameter in preCompactSelection
[
https://issues.apache.org/jira/browse/HBASE-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198536#comment-16198536
]
Hudson commented on HBASE-18949:
FAILURE: Integrated in Jenkins build HBase-2.0 #660 (See
[https://builds.apache.org/job/HBase-2.0/660/])
HBASE-18949 Remove the CompactionRequest parameter in (zhangduo: rev
294f6b786058edb93dd0327108845d2146437de0)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/mob/compactions/TestMobCompactor.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/RegionObserver.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/SimpleRegionObserver.java
> Remove the CompactionRequest parameter in preCompactSelection
> -
>
> Key: HBASE-18949
> URL: https://issues.apache.org/jira/browse/HBASE-18949
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Duo Zhang
>Assignee: Peter Somogyi
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-18949.patch, HBASE-18949.patch
>
>
> As we do not have a CompactionRequest yet when pre compaction selection so we
> always pass a null when calling which is useless...
> {code}
> override = getCoprocessorHost().preCompactSelection(this,
> candidatesForCoproc,
> tracker, null, user);
> {code}
--
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=16198545#comment-16198545 ] Eshcar Hillel commented on HBASE-16417: --- bq. So ur tests are with MSLAB feature turned OFF right? Yes all benchmarks run with MSLAB off. However, as part of the work [~anastas] is doing on cell-chunk map we are now running benchmarks with mslab and chunk pool turned on (both on HDD and SSD). We'll report the results when the experiments are completed. > 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 - Adaptive Compaction Policy - 20171001.pdf, > HBASE-16417 - parameter tuning - 20171001.pdf, HBASE-16417-V01.patch, > 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.01.patch, > HBASE-16417.02.patch, HBASE-16417.03.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18411) Dividing FiterList into two separate sub-classes: FilterListWithOR , FilterListWithAND
[ https://issues.apache.org/jira/browse/HBASE-18411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu updated HBASE-18411: - Attachment: HBASE-18411-HBASE-18410.v3.patch > Dividing FiterList into two separate sub-classes: FilterListWithOR , > FilterListWithAND > > > Key: HBASE-18411 > URL: https://issues.apache.org/jira/browse/HBASE-18411 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu > Attachments: HBASE-18411-HBASE-18410.v3.patch, HBASE-18411.v1.patch, > HBASE-18411.v1.patch, HBASE-18411.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-17049) Find out why AsyncFSWAL issues much more syncs than FSHLog
[ https://issues.apache.org/jira/browse/HBASE-17049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang resolved HBASE-17049. --- Resolution: Won't Fix Resolve as we do not care about the sync count any more. Let's put the new performance numbers in HBASE-16890. > Find out why AsyncFSWAL issues much more syncs than FSHLog > -- > > Key: HBASE-17049 > URL: https://issues.apache.org/jira/browse/HBASE-17049 > Project: HBase > Issue Type: Sub-task > Components: wal >Affects Versions: 2.0.0 >Reporter: Duo Zhang >Priority: Blocker > Fix For: 2.0.0 > > Attachments: delay-sync.patch > > > https://issues.apache.org/jira/browse/HBASE-16890?focusedCommentId=15647590&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15647590 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17633) Update unflushed sequence id in SequenceIdAccounting after flush with the minimum sequence id in memstore
[ https://issues.apache.org/jira/browse/HBASE-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17633: -- Affects Version/s: (was: 2.0.0) Fix Version/s: (was: 2.0.0) Move out of 2.0.0 as I do not have much time to do it recently. > Update unflushed sequence id in SequenceIdAccounting after flush with the > minimum sequence id in memstore > - > > Key: HBASE-17633 > URL: https://issues.apache.org/jira/browse/HBASE-17633 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-17633-v1.patch, HBASE-17633.patch > > > Now the tracking work is done by SequenceIdAccounting. And it is a little > tricky when dealing with flush. We should remove the mapping for the given > stores of a region from lowestUnflushedSequenceIds, so that we have space to > store the new lowest unflushed sequence id after flush. But we still need to > keep the old sequence ids in another map as we still need to use these values > when reporting to master to prevent data loss(think of the scenario that we > report the new lowest unflushed sequence id to master and we crashed before > actually flushed the data to disk). > And when reviewing HBASE-17407, I found that for CompactingMemStore, we have > to record the minimum sequence id.in memstore. We could just update the > mappings in SequenceIdAccounting using these values after flush. This means > we do not need to update the lowest unflushed sequence id in > SequenceIdAccounting, and also do not need to make space for the new lowest > unflushed when startCacheFlush, and also do not need the extra map to store > the old mappings. > This could simplify our logic a lot. But this is a fundamental change so I > need sometime to implement, especially for modifying tests... And I also need > sometime to check if I miss something. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-17633) Update unflushed sequence id in SequenceIdAccounting after flush with the minimum sequence id in memstore
[ https://issues.apache.org/jira/browse/HBASE-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-17633: -- Move out of 2.0.0 as I do not have much time to do it recently. > Update unflushed sequence id in SequenceIdAccounting after flush with the > minimum sequence id in memstore > - > > Key: HBASE-17633 > URL: https://issues.apache.org/jira/browse/HBASE-17633 > Project: HBase > Issue Type: Improvement > Components: wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-17633-v1.patch, HBASE-17633.patch > > > Now the tracking work is done by SequenceIdAccounting. And it is a little > tricky when dealing with flush. We should remove the mapping for the given > stores of a region from lowestUnflushedSequenceIds, so that we have space to > store the new lowest unflushed sequence id after flush. But we still need to > keep the old sequence ids in another map as we still need to use these values > when reporting to master to prevent data loss(think of the scenario that we > report the new lowest unflushed sequence id to master and we crashed before > actually flushed the data to disk). > And when reviewing HBASE-17407, I found that for CompactingMemStore, we have > to record the minimum sequence id.in memstore. We could just update the > mappings in SequenceIdAccounting using these values after flush. This means > we do not need to update the lowest unflushed sequence id in > SequenceIdAccounting, and also do not need to make space for the new lowest > unflushed when startCacheFlush, and also do not need the extra map to store > the old mappings. > This could simplify our logic a lot. But this is a fundamental change so I > need sometime to implement, especially for modifying tests... And I also need > sometime to check if I miss something. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18416) FilterLIst with MUST_PASS_ONE can be optimized to choose the mininal step to seek rather than SKIP cell one by one
[ https://issues.apache.org/jira/browse/HBASE-18416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu resolved HBASE-18416. -- Resolution: Implemented > FilterLIst with MUST_PASS_ONE can be optimized to choose the mininal step to > seek rather than SKIP cell one by one > -- > > Key: HBASE-18416 > URL: https://issues.apache.org/jira/browse/HBASE-18416 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18414) FilterList with MUST_PASS_ALL can be optimized to choose the highest key among filters in filter list to seek
[ https://issues.apache.org/jira/browse/HBASE-18414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zheng Hu resolved HBASE-18414. -- Resolution: Duplicate Duplicate with HBASE-18160 > FilterList with MUST_PASS_ALL can be optimized to choose the highest key > among filters in filter list to seek > -- > > Key: HBASE-18414 > URL: https://issues.apache.org/jira/browse/HBASE-18414 > Project: HBase > Issue Type: Sub-task >Reporter: Zheng Hu >Assignee: Zheng Hu > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18171) Scanning cursor for async client
[ https://issues.apache.org/jira/browse/HBASE-18171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang reassigned HBASE-18171: - Assignee: Duo Zhang (was: Phil Yang) > Scanning cursor for async client > > > Key: HBASE-18171 > URL: https://issues.apache.org/jira/browse/HBASE-18171 > Project: HBase > Issue Type: New Feature >Reporter: Phil Yang >Assignee: Duo Zhang > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18552) Backport the server side change in HBASE-18489 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-18552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-18552: -- Attachment: HBASE-18552-branch-1-v1.patch Rebase. > Backport the server side change in HBASE-18489 to branch-1 > -- > > Key: HBASE-18552 > URL: https://issues.apache.org/jira/browse/HBASE-18552 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.4.0, 1.5.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-18552-branch-1-v1.patch, > HBASE-18552-branch-1.patch, HBASE-18552-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17633) Update unflushed sequence id in SequenceIdAccounting after flush with the minimum sequence id in memstore
[
https://issues.apache.org/jira/browse/HBASE-17633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198622#comment-16198622
]
Hadoop QA commented on HBASE-17633:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
0s{color} | {color:blue} Docker mode activated. {color} |
| {color:red}-1{color} | {color:red} patch {color} | {color:red} 0m 5s{color}
| {color:red} HBASE-17633 does not apply to master. Rebase required? Wrong
Branch? See https://yetus.apache.org/documentation/0.4.0/precommit-patchnames
for help. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-17633 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12860636/HBASE-17633-v1.patch |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9022/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Update unflushed sequence id in SequenceIdAccounting after flush with the
> minimum sequence id in memstore
> -
>
> Key: HBASE-17633
> URL: https://issues.apache.org/jira/browse/HBASE-17633
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Attachments: HBASE-17633-v1.patch, HBASE-17633.patch
>
>
> Now the tracking work is done by SequenceIdAccounting. And it is a little
> tricky when dealing with flush. We should remove the mapping for the given
> stores of a region from lowestUnflushedSequenceIds, so that we have space to
> store the new lowest unflushed sequence id after flush. But we still need to
> keep the old sequence ids in another map as we still need to use these values
> when reporting to master to prevent data loss(think of the scenario that we
> report the new lowest unflushed sequence id to master and we crashed before
> actually flushed the data to disk).
> And when reviewing HBASE-17407, I found that for CompactingMemStore, we have
> to record the minimum sequence id.in memstore. We could just update the
> mappings in SequenceIdAccounting using these values after flush. This means
> we do not need to update the lowest unflushed sequence id in
> SequenceIdAccounting, and also do not need to make space for the new lowest
> unflushed when startCacheFlush, and also do not need the extra map to store
> the old mappings.
> This could simplify our logic a lot. But this is a fundamental change so I
> need sometime to implement, especially for modifying tests... And I also need
> sometime to check if I miss something.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18552) Backport the server side change in HBASE-18489 to branch-1
[ https://issues.apache.org/jira/browse/HBASE-18552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198626#comment-16198626 ] Duo Zhang commented on HBASE-18552: --- [~apurtell] The patch here fixes a bug when using scan cursor as described in HBASE-18489. https://issues.apache.org/jira/browse/HBASE-18489?focusedCommentId=16116194&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16116194 If no concerns let's finish this issue? Thanks. > Backport the server side change in HBASE-18489 to branch-1 > -- > > Key: HBASE-18552 > URL: https://issues.apache.org/jira/browse/HBASE-18552 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.4.0, 1.5.0 >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-18552-branch-1-v1.patch, > HBASE-18552-branch-1.patch, HBASE-18552-branch-1.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198629#comment-16198629
]
Sean Busbey commented on HBASE-18350:
-
hbase-server failure was
{code}
Tests run: 4, Failures: 1, Errors: 0, Skipped: 1, Time elapsed: 395.596 sec <<<
FAILURE! - in
org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2
testRegionReplicasOnLargeCluster(org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2)
Time elapsed: 98.183 sec <<< FAILURE!
java.lang.AssertionError
at
org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2.testRegionReplicasOnLargeCluster(TestStochasticLoadBalancer2.java:67)
Failed tests:
TestStochasticLoadBalancer2.testRegionReplicasOnLargeCluster:67->BalancerTestBase.testWithCluster:525->BalancerTestBase.testWithCluster:547->BalancerTestBase.assertClusterAsBalanced:208
{code}
But then maven failed to write the report output which is why the output
parsing in yetus got confused (I think).
> RSGroups are broken under AMv2
> --
>
> Key: HBASE-18350
> URL: https://issues.apache.org/jira/browse/HBASE-18350
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Balazs Meszaros
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-18350.master.001.patch
>
>
> The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614:
> - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what
> offline is.
> - Disabled/Ignore TestRSGroups.
> This JIRA tracks the work to enable them (or remove/modify if not applicable).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198646#comment-16198646
]
Sean Busbey commented on HBASE-18350:
-
{code}
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:E:33:17:
undefined method rsgroup_admin
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:E:35:9:
undefined method formatter
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:E:37:11:
undefined method formatter
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:E:39:9:
undefined method formatter
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:E:57:13:
undefined method formatter
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:E:68:13:
undefined method formatter
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:E:72:13:
undefined method formatter
{code}
These are all relying on methods inherited from the Command class, which
ruby-lint doesn't know about for some reason. Probably because we don't
conditionally include the file where Command is definted and ruby-lint maybe
looks at files as stand-alone entities?
In any case, this is how all our current ruby commands are done, so I don't
think you should worry about fixing it here.
> RSGroups are broken under AMv2
> --
>
> Key: HBASE-18350
> URL: https://issues.apache.org/jira/browse/HBASE-18350
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Balazs Meszaros
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-18350.master.001.patch
>
>
> The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614:
> - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what
> offline is.
> - Disabled/Ignore TestRSGroups.
> This JIRA tracks the work to enable them (or remove/modify if not applicable).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18951) Use Builder pattern to remove nullable parameters for checkAndXXX methods in RawAsyncTable/AsyncTable interface
[ https://issues.apache.org/jira/browse/HBASE-18951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198650#comment-16198650 ] Hudson commented on HBASE-18951: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3861 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3861/]) HBASE-18951 Use Builder pattern to remove nullable parameters for (zhangduo: rev 8597b19b3d7bb2671a6afd7e902aaaea6690a105) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/RawAsyncTableImpl.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncTable.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableBase.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncTableImpl.java > Use Builder pattern to remove nullable parameters for checkAndXXX methods in > RawAsyncTable/AsyncTable interface > --- > > Key: HBASE-18951 > URL: https://issues.apache.org/jira/browse/HBASE-18951 > Project: HBase > Issue Type: Sub-task > Components: asyncclient, Client >Reporter: Duo Zhang >Assignee: Duo Zhang >Priority: Blocker > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18951-v1.patch, HBASE-18951.patch > > > 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] [Commented] (HBASE-18350) RSGroups are broken under AMv2
[
https://issues.apache.org/jira/browse/HBASE-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198667#comment-16198667
]
Sean Busbey commented on HBASE-18350:
-
{code}/testptch/hbase/hbase-shell/src/main/ruby/hbase/rsgroup_admin.rb:48:7: C:
Redundant `return` detected.{code}
the "return group" here:
{code}
-
- res unless block_given?
+ return group
end
{code}
should just be "group"
{code}
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:32:7:
C: Assignment Branch Condition size for command is too high. [20.02/15]
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/get_rsgroup.rb:32:7:
C: Method has too many lines. [11/10]
{code}
The method looks fine to me. Should silence Rubocop here.
{code}
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:42:11:
C: Favor modifier `if` usage when having a single-line body. Another good
alternative is the usage of control flow `&&`/`||`.
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:42:11:
C: Favor `unless` over `if` for negative conditions.
{code}
This is saying that in this case:
{code}
- formatter.row([group])
+ if !group.getName.match(regex)
+next
+ end
{code}
you should instead say {{next unless group.getName.match(regex)}}
{code}
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:71:11:
C: Favor modifier `if` usage when having a single-line body. Another good
alternative is the usage of control flow `&&`/`||`.
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:71:11:
C: Favor `unless` over `if` for negative conditions.
{code}
this is saying that in this case:
{code}
+ if !group_name_printed
+formatter.row([group.getName, ''])
+ end
{code}
you should instead say {{formatter.row(\[group.getName,''\]) unless
group_name_printed}}
{code}
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:34:7:
C: Assignment Branch Condition size for command is too high. [31.78/15]
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:34:7:
C: Method has too many lines. [33/10]
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:34:7:
C: Perceived complexity for command is too high. [8/7]
/testptch/hbase/hbase-shell/src/main/ruby/shell/commands/list_rsgroups.rb:41:9:
C: Block has too many lines. [26/25]
{code}
All of these point to "Shell::Command::ListRsgroups#command" is too
complicated. I agree with rubocop, but I don't see a way this can be
meaningfully simplified given our current shell codebase, so I think you should
silence these as well.
> RSGroups are broken under AMv2
> --
>
> Key: HBASE-18350
> URL: https://issues.apache.org/jira/browse/HBASE-18350
> Project: HBase
> Issue Type: Bug
> Components: rsgroup
>Affects Versions: 2.0.0-alpha-1
>Reporter: Stephen Yuan Jiang
>Assignee: Balazs Meszaros
>Priority: Blocker
> Fix For: 2.0.0-beta-2
>
> Attachments: HBASE-18350.master.001.patch
>
>
> The following RSGroups tests were disabled by Core Proc-V2 AM in HBASE-14614:
> - Disabled/Ignore TestRSGroupsOfflineMode#testOffline; need to dig in on what
> offline is.
> - Disabled/Ignore TestRSGroups.
> This JIRA tracks the work to enable them (or remove/modify if not applicable).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198713#comment-16198713 ] Ted Yu commented on HBASE-15410: [~busbey]: Do you want to take a look ? > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (HBASE-18979) TestInterfaceAudienceAnnotations fails on branch-1.3
Mike Drob created HBASE-18979:
-
Summary: TestInterfaceAudienceAnnotations fails on branch-1.3
Key: HBASE-18979
URL: https://issues.apache.org/jira/browse/HBASE-18979
Project: HBase
Issue Type: Test
Components: Client
Reporter: Mike Drob
Priority: Blocker
Fix For: 1.3.2
{noformat}
2017-10-10 09:15:15,609 INFO [main]
hbase.TestInterfaceAudienceAnnotations(254): These are the classes that DO NOT
have @InterfaceAudience annotation:
2017-10-10 09:15:15,609 INFO [main]
hbase.TestInterfaceAudienceAnnotations(256): class
org.apache.hadoop.hbase.Version
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18867) maven enforcer plugin needs update to work with jdk9
[
https://issues.apache.org/jira/browse/HBASE-18867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198734#comment-16198734
]
Mike Drob commented on HBASE-18867:
---
The branch-1.3 failure occurs without the patch for me as well. Filing
HBASE-18979 to track it.
> maven enforcer plugin needs update to work with jdk9
>
>
> Key: HBASE-18867
> URL: https://issues.apache.org/jira/browse/HBASE-18867
> Project: HBase
> Issue Type: Sub-task
> Components: build
>Affects Versions: 2.0.0-alpha-3
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Blocker
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13
>
> Attachments: HBASE-18867.0.patch, HBASE-18867.branch-1.3.patch,
> HBASE-18867.branch-1.patch
>
>
> build fails under jdk9, even when targeting java 8
> {code}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce
> (min-maven-min-java-banned-xerces) on project hbase: Execution
> min-maven-min-java-banned-xerces of goal
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce failed: An API
> incompatibility was encountered while executing
> org.apache.maven.plugins:maven-enforcer-plugin:1.4:enforce:
> java.lang.ExceptionInInitializerError: null
> [ERROR] -
> [ERROR] realm =plugin>org.apache.maven.plugins:maven-enforcer-plugin:1.4
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugins/maven-enforcer-plugin/1.4/maven-enforcer-plugin-1.4.jar
> [ERROR] urls[1] =
> file:/Users/busbey/.m2/repository/org/codehaus/mojo/extra-enforcer-rules/1.0-beta-6/extra-enforcer-rules-1.0-beta-6.jar
> [ERROR] urls[2] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-dependency-tree/2.2/maven-dependency-tree-2.2.jar
> [ERROR] urls[3] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[4] =
> file:/Users/busbey/.m2/repository/org/eclipse/aether/aether-util/0.9.0.M2/aether-util-0.9.0.M2.jar
> [ERROR] urls[5] =
> file:/Users/busbey/.m2/repository/org/apache/maven/shared/maven-common-artifact-filters/1.4/maven-common-artifact-filters-1.4.jar
> [ERROR] urls[6] =
> file:/Users/busbey/.m2/repository/com/ibm/icu/icu4j/56.1/icu4j-56.1.jar
> [ERROR] urls[7] =
> file:/Users/busbey/.m2/repository/backport-util-concurrent/backport-util-concurrent/3.1/backport-util-concurrent-3.1.jar
> [ERROR] urls[8] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.11/plexus-interpolation-1.11.jar
> [ERROR] urls[9] =
> file:/Users/busbey/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar
> [ERROR] urls[10] =
> file:/Users/busbey/.m2/repository/org/slf4j/jcl-over-slf4j/1.5.6/jcl-over-slf4j-1.5.6.jar
> [ERROR] urls[11] =
> file:/Users/busbey/.m2/repository/org/apache/maven/reporting/maven-reporting-api/2.2.1/maven-reporting-api-2.2.1.jar
> [ERROR] urls[12] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-sink-api/1.1/doxia-sink-api-1.1.jar
> [ERROR] urls[13] =
> file:/Users/busbey/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.1/doxia-logging-api-1.1.jar
> [ERROR] urls[14] =
> file:/Users/busbey/.m2/repository/commons-cli/commons-cli/1.2/commons-cli-1.2.jar
> [ERROR] urls[15] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-interactivity-api/1.0-alpha-4/plexus-interactivity-api-1.0-alpha-4.jar
> [ERROR] urls[16] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[17] =
> file:/Users/busbey/.m2/repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> [ERROR] urls[18] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[19] =
> file:/Users/busbey/.m2/repository/commons-lang/commons-lang/2.3/commons-lang-2.3.jar
> [ERROR] urls[20] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-api/1.4/enforcer-api-1.4.jar
> [ERROR] urls[21] =
> file:/Users/busbey/.m2/repository/org/apache/maven/enforcer/enforcer-rules/1.4/enforcer-rules-1.4.jar
> [ERROR] urls[22] =
> file:/Users/busbey/.m2/repository/org/beanshell/bsh/2.0b4/bsh-2.0b4.jar
> [ERROR] urls[23] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
> [ERROR] urls[24] =
> file:/Users/busbey/.m2/repository/org/apache/maven/plugin-testing/maven-plugin-testing-harness/1.3/maven-plugin-testing-harness-1.3.jar
> [ERROR] urls[25] =
> file:/Users/busbey/.m2/repository/org/codehaus/plexus/plexus-archiver/
[jira] [Commented] (HBASE-14093) deduplicate copies of bootstrap files
[ https://issues.apache.org/jira/browse/HBASE-14093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198741#comment-16198741 ] Mike Drob commented on HBASE-14093: --- tab.js is not third-party code, we should go ahead and fix the whitespace there. Why are we unpacking the webjar and then moving it to a different directory in two steps? Why not unpack it into the correct directory to begin with? Probably could add a comment to the build to explain this, there's already enough maven magic in the build that I don't think we need any more. Do we still need the maven 2.2 workaround in the jar plugin? Our minimum is Maven 3.0.3 for a long time now. Can we upgrade from Bootstrap 3.0.0 to something newer? The latest is 3.3.7 and probably has a lot of fixes and improvements. > deduplicate copies of bootstrap files > - > > Key: HBASE-14093 > URL: https://issues.apache.org/jira/browse/HBASE-14093 > Project: HBase > Issue Type: Improvement > Components: build >Reporter: Sean Busbey >Assignee: Tamas Penzes > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14093.master.001.patch, > HBASE-14093.master.002.patch, HBASE-14093.master.002.patch, > HBASE-14093.master.003.patch, HBASE-14093.master.003.patch, > patch-shadedjars.txt > > > right now we have a couple of different copies of the bootstrap js and css > files. It'll be easier to maintain them later if we can centralize. > Move them to a common location and use maven to populate them as needed in > various component build directories. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18183) Region interface cleanup for CP expose
[ https://issues.apache.org/jira/browse/HBASE-18183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-18183: --- Attachment: HBASE-18183_V2.patch V2 patch rebased/reworked. Fixed few comments got on V1 patch. On the discussed APIs (to be kept in Region or not), - As of now removed the getter for MetricsRegion with a TODO to handle it later in another issue - Removed the wait for methods, we have a new issue for supporting what Phoenix needs - Kept the row locking (and start/end RegionOperation) APIs in Region as of now. To be revisited based on what we decide abt RowProcessor. We can fine tune later with other subtasks. The patch is big and lets get this in before any need for further rebase/rework. Pls review > Region interface cleanup for CP expose > -- > > Key: HBASE-18183 > URL: https://issues.apache.org/jira/browse/HBASE-18183 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18183.patch, HBASE-18183_V2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18693) adding an option to restore_snapshot to move mob files from archive dir to working dir
[ https://issues.apache.org/jira/browse/HBASE-18693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198767#comment-16198767 ] Mike Drob commented on HBASE-18693: --- The rubocop & ruby-lint warnings look fine to ignore for now. We'll need to do a major cleanup pass later on line length anyway. > adding an option to restore_snapshot to move mob files from archive dir to > working dir > -- > > Key: HBASE-18693 > URL: https://issues.apache.org/jira/browse/HBASE-18693 > Project: HBase > Issue Type: Improvement > Components: mob >Affects Versions: 2.0.0-alpha-2 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-18693.master.001.patch > > > Today, there is a single mob region where mob files for all user regions are > saved. There could be many files (one million) in a single mob directory. > When one mob table is restored or cloned from snapshot, links are created for > these mob files. This creates a scaling issue for mob compaction. In mob > compaction's select() logic, for each hFileLink, it needs to call NN's > getFileStatus() to get the size of the linked hfile. Assume that one such > call takes 20ms, 20ms * 100 = 6 hours. > To avoid this overhead, we want to add an option so that restore_snapshot can > move mob files from archive dir to working dir. clone_snapshot is more > complicated as it can clone a snapshot to a different table so moving that > can destroy the snapshot. No option will be added for clone_snapshot. -- 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=16198782#comment-16198782 ] Mike Drob commented on HBASE-18925: --- Visually inspected v3 patch, looks good to me. Let's figure out the QA failures and then get this in! > 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] [Commented] (HBASE-18842) The hbase shell clone_snaphost command returns bad error message
[
https://issues.apache.org/jira/browse/HBASE-18842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198811#comment-16198811
]
Jesse Yates commented on HBASE-18842:
-
Failure looks unrelated and passed with #3860.
> The hbase shell clone_snaphost command returns bad error message
>
>
> Key: HBASE-18842
> URL: https://issues.apache.org/jira/browse/HBASE-18842
> Project: HBase
> Issue Type: Bug
>Reporter: Thoralf Gutierrez
>Assignee: Jesse Yates
>Priority: Minor
> Fix For: 2.0.0, 3.0.0
>
> Attachments:
> 0001-HBASE-18842-Fix-unknown-namespace-message-in-clone_s.patch,
> 0002-HBASE-18842-Fix-unknown-namespace-message-in-clone_s.patch,
> 0003-HBASE-18842-Fix-unknown-namespace-message-in-clone_s.patch,
> 0004-HBASE-18842-Fix-unknown-namespace-message-in-clone_s.patch,
> 0005-HBASE-18842-Fix-unknown-namespace-message-in-clone_s.patch
>
>
> When you call the hbase shell clone_snapshot command with a target namespace
> that doesn't exist, you get an error message, but the variable used to
> identify the inexistent namespace is wrong:
> {noformat}
> hbase(main):001:0> clone_snapshot 'someSnapshotName',
> 'someNamespaceName:someTableName'
> ERROR: Unknown namespace someSnapshotName!
> Create a new table by cloning the snapshot content.
> There're no copies of data involved.
> And writing on the newly created table will not influence the snapshot data.
> Examples:
> hbase> clone_snapshot 'snapshotName', 'tableName'
> hbase> clone_snapshot 'snapshotName', 'namespace:tableName'
> {noformat}
> It should rather say:
> {noformat}
> ERROR: Unknown namespace someNamespaceName!
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18959) Backport HBASE-18874 (HMaster abort message will be skipped if Throwable is passed null) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-18959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-18959: --- Hadoop Flags: Reviewed Fix Version/s: 1.5.0 Pushed to branch-1 Let's see how Jenkins goes. > Backport HBASE-18874 (HMaster abort message will be skipped if Throwable is > passed null) to branch-1 > > > Key: HBASE-18959 > URL: https://issues.apache.org/jira/browse/HBASE-18959 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.3.2, 1.5.0, 1.2.7 >Reporter: Pankaj Kumar >Assignee: Pankaj Kumar >Priority: Minor > Fix For: 1.5.0 > > Attachments: HBASE-18959-branch-1.patch > > > Backport HBASE-18874 to branch-1/1.4/1.3/1.2. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198857#comment-16198857 ] Sean Busbey commented on HBASE-15410: - looking at this today. Do you have a proposed release note for the behavior change to go with this? > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198866#comment-16198866 ] Sean Busbey commented on HBASE-18410: - Welcome back [~openinx], sorry for all the churn. I figure once we have the HBASE-18410 branch ready for the mater branch we can merge it there (or rebase + push) and then backport needed changes to branch-2 and earlier. If it looks like a given backport will be very messy (e.g. for branch-1) we can start a feature branch to work out the details. > FilterList Improvement. > - > > Key: HBASE-18410 > URL: https://issues.apache.org/jira/browse/HBASE-18410 > Project: HBase > Issue Type: Umbrella > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > > FilterList.java is complex now, and we have found some improvements for it. > So create an issue to address it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198869#comment-16198869 ] Sean Busbey commented on HBASE-18410: - Also worth noting, I'm more concerned about us getting to a point where we can get this branch merged in time for 2.0.0-beta-1 rather than e.g. in time for 1.4.0. > FilterList Improvement. > - > > Key: HBASE-18410 > URL: https://issues.apache.org/jira/browse/HBASE-18410 > Project: HBase > Issue Type: Umbrella > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Fix For: 2.0.0-beta-1 > > > FilterList.java is complex now, and we have found some improvements for it. > So create an issue to address it. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18411) Dividing FiterList into two separate sub-classes: FilterListWithOR , FilterListWithAND
[ https://issues.apache.org/jira/browse/HBASE-18411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18411: Component/s: Filters > Dividing FiterList into two separate sub-classes: FilterListWithOR , > FilterListWithAND > > > Key: HBASE-18411 > URL: https://issues.apache.org/jira/browse/HBASE-18411 > Project: HBase > Issue Type: Sub-task > Components: Filters >Reporter: Zheng Hu >Assignee: Zheng Hu > Attachments: HBASE-18411-HBASE-18410.v3.patch, HBASE-18411.v1.patch, > HBASE-18411.v1.patch, HBASE-18411.v2.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15410: --- Release Note: This optimization, targeting SEEK_NEXT_USING_HINT return values, utilizes the max seek value and is transparent to Filters. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198887#comment-16198887 ] Sean Busbey commented on HBASE-15410: - Are the changes in TestFilterList intentional? I don't expect an optimization as described in the release notes to require changing test behavior. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-15410) Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198889#comment-16198889 ] Ted Yu commented on HBASE-15410: The changes in TestFilterList are due to the optimization. > Utilize the max seek value when all Filters in MUST_PASS_ALL FilterList > return SEEK_NEXT_USING_HINT > --- > > Key: HBASE-15410 > URL: https://issues.apache.org/jira/browse/HBASE-15410 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Labels: filter, perfomance > Fix For: 1.5.0, 2.0.0-alpha-3, HBASE-18410 > > Attachments: 15410-wip.patch, 15410.branch-1.patch, 15410.v1.patch, > 15410.v2.patch, 15410.v3.patch > > > As Preston mentioned in the comment in HBASE-15243: > https://issues.apache.org/jira/browse/HBASE-15243?focusedCommentId=15143557&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15143557 > An optimization for filters returning a SEEK_NEXT_USING_HINT would be to seek > to the highest hint (Any previous/lower row won't be accepted by the filter > returning that seek). > This JIRA is to explore this potential optimization. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18975) B&R hadoop3 incompatibility
[
https://issues.apache.org/jira/browse/HBASE-18975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198892#comment-16198892
]
Ted Yu commented on HBASE-18975:
Looking at DistCp.java , the NullPointerException came from this line:
{code}
jobFS.delete(metaFolder, true);
{code}
I have outlined the procedure for testing against hadoop3 in HBASE-18843
> B&R hadoop3 incompatibility
> ---
>
> Key: HBASE-18975
> URL: https://issues.apache.org/jira/browse/HBASE-18975
> Project: HBase
> Issue Type: Bug
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
> Attachments: HBASE-18975-v1.patch, HBASE-18975-v2.patch,
> testIncrementalBackup-output.tar.gz
>
>
> Due to changes in hadoop 3, reflection in BackupDistCp is broken
> {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}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
Mike Drob created HBASE-18980: - Summary: Address issues found by error-prone in hbase-hadoop2-compat Key: HBASE-18980 URL: https://issues.apache.org/jira/browse/HBASE-18980 Project: HBase Issue Type: Test Reporter: Mike Drob Assignee: Mike Drob Priority: Trivial There are a few instances of self comparison found in hadoop2-compat module. Because they are in tests specifically for verifying compareTo, I think they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18980: -- Issue Type: Sub-task (was: Test) Parent: HBASE-12187 > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18980: -- Status: Patch Available (was: Open) > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18980: -- Attachment: HBASE-18980.patch v1: Add @SuppressWarning annotation to the two tests where we do self comparison. > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18980: -- Fix Version/s: 1.1.13 2.0.0-beta-1 1.2.7 1.5.0 1.3.2 1.4.0 3.0.0 > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198939#comment-16198939 ] stack commented on HBASE-18980: --- +1 > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 2.0.0-beta-1, 1.1.13 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-16338: -- Attachment: HBASE-16338.v7.patch v7: * Add jackson-scala module (and exclude scala-lang!) * Remove wildcard exclusions from hadoop and manually list org.codehaus modules > 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, > HBASE-16338.v5.patch, HBASE-16338.v6.patch, HBASE-16338.v7.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-16338) update jackson to 2.y
[ https://issues.apache.org/jira/browse/HBASE-16338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-16338: -- Release Note: HBase has upgraded from Jackson 1 to Jackson 2. JSON output should not have changed and this should not be user facing, but server classpaths should be adjusted accordingly. > 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, > HBASE-16338.v5.patch, HBASE-16338.v6.patch, HBASE-16338.v7.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=16198970#comment-16198970 ] Hadoop QA commented on HBASE-16338: --- (!) 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/9025/console in case of problems. > 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, > HBASE-16338.v5.patch, HBASE-16338.v6.patch, HBASE-16338.v7.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-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Drob updated HBASE-18980: -- Resolution: Fixed Fix Version/s: (was: 2.0.0-beta-1) (was: 1.5.0) 2.0.0-alpha-4 Status: Resolved (was: Patch Available) Thanks Stack! Pushed to all the branches. > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198987#comment-16198987 ] Mike Drob commented on HBASE-18873: --- ping [~elserj] - do you still think this is something that is important for alpha4, or is it safe to push out to the betas? > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18770) We should not allow RegionObserver.preBulkLoadHFile to bypass the default behavior
[ https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198996#comment-16198996 ] Mike Drob commented on HBASE-18770: --- [~Apache9] do you still have cycles to pick this up? Or [~stack], do you have somebody on your end that you think can take it? It seems like maybe this can go to beta1 instead of blocking alpha4? > We should not allow RegionObserver.preBulkLoadHFile to bypass the default > behavior > -- > > Key: HBASE-18770 > URL: https://issues.apache.org/jira/browse/HBASE-18770 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang > Fix For: 2.0.0-alpha-4 > > > As now we do not allow users to create a StoreFile instance. Users can still > select the files to be bulk loaded by modifying the familyPaths passed in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[
https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199002#comment-16199002
]
Hadoop QA commented on HBASE-18980:
---
| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
9s{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 2 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
12s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
15s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
11s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
12s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{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} 3m
58s{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:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
33s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
31s{color} | {color:green} hbase-hadoop2-compat in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
9s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 46m 22s{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-18980 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891294/HBASE-18980.patch |
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f913555fbbd4 3.13.0-129-generic #178-Ubuntu SMP Fri Aug 11
12:48:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 8597b19 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9024/testReport/ |
| modules | C: hbase-hadoop2-compat U: hbase-hadoop2-compat |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9024/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> Address issues found by error-prone in hbase-hadoop2-
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199015#comment-16199015 ] Hudson commented on HBASE-18980: FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #314 (See [https://builds.apache.org/job/HBase-1.3-JDK8/314/]) HBASE-18980 Suppress SelfComparison error in tests (mdrob: rev 04fa819e0aa546f84891601653bf4499c46724e9) * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionSourceImpl.java * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsTableSourceImpl.java > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199011#comment-16199011 ] Hudson commented on HBASE-18980: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #228 (See [https://builds.apache.org/job/HBase-1.3-IT/228/]) HBASE-18980 Suppress SelfComparison error in tests (mdrob: rev 04fa819e0aa546f84891601653bf4499c46724e9) * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsTableSourceImpl.java * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionSourceImpl.java > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18693) adding an option to restore_snapshot to move mob files from archive dir to working dir
[ https://issues.apache.org/jira/browse/HBASE-18693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199017#comment-16199017 ] huaxiang sun commented on HBASE-18693: -- Thanks [~dujin...@gmail.com] and [~mdrob], I will take care of the comments. > adding an option to restore_snapshot to move mob files from archive dir to > working dir > -- > > Key: HBASE-18693 > URL: https://issues.apache.org/jira/browse/HBASE-18693 > Project: HBase > Issue Type: Improvement > Components: mob >Affects Versions: 2.0.0-alpha-2 >Reporter: huaxiang sun >Assignee: huaxiang sun > Attachments: HBASE-18693.master.001.patch > > > Today, there is a single mob region where mob files for all user regions are > saved. There could be many files (one million) in a single mob directory. > When one mob table is restored or cloned from snapshot, links are created for > these mob files. This creates a scaling issue for mob compaction. In mob > compaction's select() logic, for each hFileLink, it needs to call NN's > getFileStatus() to get the size of the linked hfile. Assume that one such > call takes 20ms, 20ms * 100 = 6 hours. > To avoid this overhead, we want to add an option so that restore_snapshot can > move mob files from archive dir to working dir. clone_snapshot is more > complicated as it can clone a snapshot to a different table so moving that > can destroy the snapshot. No option will be added for clone_snapshot. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-18979) TestInterfaceAudienceAnnotations fails on branch-1.3
[
https://issues.apache.org/jira/browse/HBASE-18979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Purtell reassigned HBASE-18979:
--
Assignee: Andrew Purtell
Fix Version/s: 1.1.13
1.2.7
1.5.0
1.4.0
3.0.0
2.0.0
Version.java is a generated file, created by hbase-common/src/saveVersion.sh.
I'm not sure why the test is picking it up now when it did not before. However
we can add a Private interface annotation in the boilerplate for the generated
file, and just start doing this everywhere. Let me work up a quick patch.
> TestInterfaceAudienceAnnotations fails on branch-1.3
>
>
> Key: HBASE-18979
> URL: https://issues.apache.org/jira/browse/HBASE-18979
> Project: HBase
> Issue Type: Test
> Components: Client
>Reporter: Mike Drob
>Assignee: Andrew Purtell
>Priority: Blocker
> Fix For: 2.0.0, 3.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7, 1.1.13
>
>
> {noformat}
> 2017-10-10 09:15:15,609 INFO [main]
> hbase.TestInterfaceAudienceAnnotations(254): These are the classes that DO
> NOT have @InterfaceAudience annotation:
> 2017-10-10 09:15:15,609 INFO [main]
> hbase.TestInterfaceAudienceAnnotations(256): class
> org.apache.hadoop.hbase.Version
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18397) StoreFile accounting issues on branch-1.3 and branch-1
[
https://issues.apache.org/jira/browse/HBASE-18397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199026#comment-16199026
]
Andrew Purtell commented on HBASE-18397:
+1 [~mantonov]
> StoreFile accounting issues on branch-1.3 and branch-1
> --
>
> Key: HBASE-18397
> URL: https://issues.apache.org/jira/browse/HBASE-18397
> Project: HBase
> Issue Type: Umbrella
> Components: regionserver, Scanners
>Affects Versions: 1.3.0
>Reporter: Mikhail Antonov
>Priority: Critical
> Fix For: 2.0.0, 1.3.2
>
>
> This jira is an umbrella for a set of issues around store file accounting on
> branch-1.3 and branch-1 (I believe).
> At this point I do believe that many / most of those issues are related to
> backport of HBASE-13082 done long time ago. A number of related issues were
> identified and fixed previously, but some still yet to be debugged and fixed.
> I think that this class of problems prevents us from releasing 1.3.2 and
> moving stable pointer to branch 1.3 at this point, so marking as critical.
> Below is overview by Andrew Purtell from dev list: (Subject: _Re: Branch 1.4
> update_):
> {quote}
> Let me provide some context.
> The root issue was fallout from a locking change introduced just prior to
> release of 1.3. That change was HBASE-13082. Lars H proposed a change. It
> was committed to trunk but quickly reverted. After the revert Lars decided
> to drop the work rather than fix it for reapplication. However, the work
> was picked up by others and eventually found its way into branch-1, then
> branch-1.3, then 1.3.x releases. There were unintended side effects,
> causing bugs. The umbrella issue HBASE-18397 tracks a bunch of fix work the
> community has done since. The last known bug fix was HBASE-18771, found and
> fixed by our Abhishek. The last known change I know of was work I did on
> HBASE-18786 to remove some dodgy exception handling (prefer aborts to
> silent data corruption). Is this enough to move the stable pointer?
> According to our testing at Salesforce, yes, so far. We have yet to run in
> full production. Give us a few months of that and my answer will be
> unconditional one way or another. According to some offline conversation
> with Mikhail and Gary, the answer is in fact no, they still have one hairy
> use case causing occasional problems that look like more of this, but that
> feedback predates HBASE-18771.{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199028#comment-16199028 ] Hudson commented on HBASE-18980: FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #235 (See [https://builds.apache.org/job/HBase-1.2-JDK7/235/]) HBASE-18980 Suppress SelfComparison error in tests (mdrob: rev fd8d4e24ba50683c0e9243c850dc24b46c8a4a1c) * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionSourceImpl.java > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199032#comment-16199032 ] Anoop Sam John commented on HBASE-18873: alpha4 is supposed to do all CP cleanups. So better we can do this. > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Improvement >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-18873: --- Issue Type: Sub-task (was: Improvement) Parent: HBASE-18169 > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18770) We should not allow RegionObserver.preBulkLoadHFile to bypass the default behavior
[ https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199038#comment-16199038 ] stack commented on HBASE-18770: --- [~mdrob] I think we need to start the conversation around bypass generally; suggestion has been made that we shut it down totally for CPs in 2.0. Would make some stuff easier of course but need to figure cost/pain to downstreamers. > We should not allow RegionObserver.preBulkLoadHFile to bypass the default > behavior > -- > > Key: HBASE-18770 > URL: https://issues.apache.org/jira/browse/HBASE-18770 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang > Fix For: 2.0.0-alpha-4 > > > As now we do not allow users to create a StoreFile instance. Users can still > select the files to be bulk loaded by modifying the familyPaths passed in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18786) FileNotFoundException should not be silently handled for primary region replicas
[ https://issues.apache.org/jira/browse/HBASE-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18786: --- Attachment: HBASE-18786-branch-1.3.patch > FileNotFoundException should not be silently handled for primary region > replicas > > > Key: HBASE-18786 > URL: https://issues.apache.org/jira/browse/HBASE-18786 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Ashu Pachauri >Assignee: Andrew Purtell > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.5.0 > > Attachments: HBASE-18786-branch-1.3.patch, > HBASE-18786-branch-1.patch, HBASE-18786-branch-1.patch, HBASE-18786.patch, > HBASE-18786.patch > > > This is a follow up for HBASE-18186. > FileNotFoundException while scanning from a primary region replica can be > indicative of a more severe problem. Handling them silently can cause many > underlying issues go undetected. We should either > 1. Hard fail the regionserver if there is a FNFE on a primary region replica, > OR > 2. Report these exceptions as some region / server level metric so that these > can be proactively investigated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18786) FileNotFoundException should not be silently handled for primary region replicas
[ https://issues.apache.org/jira/browse/HBASE-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199036#comment-16199036 ] Andrew Purtell commented on HBASE-18786: Removed the 1.3 fixVersion here for now. > FileNotFoundException should not be silently handled for primary region > replicas > > > Key: HBASE-18786 > URL: https://issues.apache.org/jira/browse/HBASE-18786 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Ashu Pachauri >Assignee: Andrew Purtell > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.5.0 > > Attachments: HBASE-18786-branch-1.3.patch, > HBASE-18786-branch-1.patch, HBASE-18786-branch-1.patch, HBASE-18786.patch, > HBASE-18786.patch > > > This is a follow up for HBASE-18186. > FileNotFoundException while scanning from a primary region replica can be > indicative of a more severe problem. Handling them silently can cause many > underlying issues go undetected. We should either > 1. Hard fail the regionserver if there is a FNFE on a primary region replica, > OR > 2. Report these exceptions as some region / server level metric so that these > can be proactively investigated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18786) FileNotFoundException should not be silently handled for primary region replicas
[ https://issues.apache.org/jira/browse/HBASE-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18786: --- Fix Version/s: (was: 1.3.2) > FileNotFoundException should not be silently handled for primary region > replicas > > > Key: HBASE-18786 > URL: https://issues.apache.org/jira/browse/HBASE-18786 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Ashu Pachauri >Assignee: Andrew Purtell > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.5.0 > > Attachments: HBASE-18786-branch-1.3.patch, > HBASE-18786-branch-1.patch, HBASE-18786-branch-1.patch, HBASE-18786.patch, > HBASE-18786.patch > > > This is a follow up for HBASE-18186. > FileNotFoundException while scanning from a primary region replica can be > indicative of a more severe problem. Handling them silently can cause many > underlying issues go undetected. We should either > 1. Hard fail the regionserver if there is a FNFE on a primary region replica, > OR > 2. Report these exceptions as some region / server level metric so that these > can be proactively investigated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18786) FileNotFoundException should not be silently handled for primary region replicas
[ https://issues.apache.org/jira/browse/HBASE-18786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199034#comment-16199034 ] Andrew Purtell commented on HBASE-18786: [~mantonov] That's a mistake on the JIRA. No commit to 1.3. Do you want it? Attaching a patch for 1.3. > FileNotFoundException should not be silently handled for primary region > replicas > > > Key: HBASE-18786 > URL: https://issues.apache.org/jira/browse/HBASE-18786 > Project: HBase > Issue Type: Sub-task > Components: regionserver, Scanners >Reporter: Ashu Pachauri >Assignee: Andrew Purtell > Fix For: 2.0.0, 3.0.0, 1.4.0, 1.5.0 > > Attachments: HBASE-18786-branch-1.3.patch, > HBASE-18786-branch-1.patch, HBASE-18786-branch-1.patch, HBASE-18786.patch, > HBASE-18786.patch > > > This is a follow up for HBASE-18186. > FileNotFoundException while scanning from a primary region replica can be > indicative of a more severe problem. Handling them silently can cause many > underlying issues go undetected. We should either > 1. Hard fail the regionserver if there is a FNFE on a primary region replica, > OR > 2. Report these exceptions as some region / server level metric so that these > can be proactively investigated. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18770) We should not allow RegionObserver.preBulkLoadHFile to bypass the default behavior
[ https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199040#comment-16199040 ] Andrew Purtell commented on HBASE-18770: +1 to removing bypass Let me start a discussion on dev@. > We should not allow RegionObserver.preBulkLoadHFile to bypass the default > behavior > -- > > Key: HBASE-18770 > URL: https://issues.apache.org/jira/browse/HBASE-18770 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang > Fix For: 2.0.0-alpha-4 > > > As now we do not allow users to create a StoreFile instance. Users can still > select the files to be bulk loaded by modifying the familyPaths passed in. -- 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=16199041#comment-16199041 ] stack commented on HBASE-18601: --- Do the failed tests in the above (as opposed to the timedout tests) pass for you [~tamaas] ? Thanks. > 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, > HBASE-18601.master.009.patch, HBASE-18601.master.009.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-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199044#comment-16199044 ] Hudson commented on HBASE-18980: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #968 (See [https://builds.apache.org/job/HBase-1.2-IT/968/]) HBASE-18980 Suppress SelfComparison error in tests (mdrob: rev fd8d4e24ba50683c0e9243c850dc24b46c8a4a1c) * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionSourceImpl.java > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18770) We should not allow RegionObserver.preBulkLoadHFile to bypass the default behavior
[ https://issues.apache.org/jira/browse/HBASE-18770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199053#comment-16199053 ] stack commented on HBASE-18770: --- Thanks [~apurtell]. I had started one but was trying to come off as authoritative and was failing... [~mdrob] CPs being able to by-pass or not seems like alpha-4 territory. > We should not allow RegionObserver.preBulkLoadHFile to bypass the default > behavior > -- > > Key: HBASE-18770 > URL: https://issues.apache.org/jira/browse/HBASE-18770 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Duo Zhang > Fix For: 2.0.0-alpha-4 > > > As now we do not allow users to create a StoreFile instance. Users can still > select the files to be bulk loaded by modifying the familyPaths passed in. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18980) Address issues found by error-prone in hbase-hadoop2-compat
[ https://issues.apache.org/jira/browse/HBASE-18980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199054#comment-16199054 ] Hudson commented on HBASE-18980: FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #300 (See [https://builds.apache.org/job/HBase-1.3-JDK7/300/]) HBASE-18980 Suppress SelfComparison error in tests (mdrob: rev 04fa819e0aa546f84891601653bf4499c46724e9) * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsRegionSourceImpl.java * (edit) hbase-hadoop2-compat/src/test/java/org/apache/hadoop/hbase/regionserver/TestMetricsTableSourceImpl.java > Address issues found by error-prone in hbase-hadoop2-compat > --- > > Key: HBASE-18980 > URL: https://issues.apache.org/jira/browse/HBASE-18980 > Project: HBase > Issue Type: Sub-task >Reporter: Mike Drob >Assignee: Mike Drob >Priority: Trivial > Fix For: 3.0.0, 1.4.0, 1.3.2, 1.2.7, 1.1.13, 2.0.0-alpha-4 > > Attachments: HBASE-18980.patch > > > There are a few instances of self comparison found in hadoop2-compat module. > Because they are in tests specifically for verifying compareTo, I think > they're ok to keep and we should suppress them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Status: Open (was: Patch Available) > 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 > > Attachments: HBASE-18495.patch > > > 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. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Attachment: HBASE-18945_2.patch Renamed the new interface to CPCellComparator and the actual CellComparator implements it. Still am not very sure on the name. /suggestions welcome. > 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 > > Attachments: HBASE-18495.patch, HBASE-18945_2.patch > > > 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. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18397) StoreFile accounting issues on branch-1.3 and branch-1
[
https://issues.apache.org/jira/browse/HBASE-18397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199068#comment-16199068
]
ramkrishna.s.vasudevan commented on HBASE-18397:
+1. If the initial file not found issue happens then that compaction/splits
related issue happens. +1 to your suggstion.
> StoreFile accounting issues on branch-1.3 and branch-1
> --
>
> Key: HBASE-18397
> URL: https://issues.apache.org/jira/browse/HBASE-18397
> Project: HBase
> Issue Type: Umbrella
> Components: regionserver, Scanners
>Affects Versions: 1.3.0
>Reporter: Mikhail Antonov
>Priority: Critical
> Fix For: 2.0.0, 1.3.2
>
>
> This jira is an umbrella for a set of issues around store file accounting on
> branch-1.3 and branch-1 (I believe).
> At this point I do believe that many / most of those issues are related to
> backport of HBASE-13082 done long time ago. A number of related issues were
> identified and fixed previously, but some still yet to be debugged and fixed.
> I think that this class of problems prevents us from releasing 1.3.2 and
> moving stable pointer to branch 1.3 at this point, so marking as critical.
> Below is overview by Andrew Purtell from dev list: (Subject: _Re: Branch 1.4
> update_):
> {quote}
> Let me provide some context.
> The root issue was fallout from a locking change introduced just prior to
> release of 1.3. That change was HBASE-13082. Lars H proposed a change. It
> was committed to trunk but quickly reverted. After the revert Lars decided
> to drop the work rather than fix it for reapplication. However, the work
> was picked up by others and eventually found its way into branch-1, then
> branch-1.3, then 1.3.x releases. There were unintended side effects,
> causing bugs. The umbrella issue HBASE-18397 tracks a bunch of fix work the
> community has done since. The last known bug fix was HBASE-18771, found and
> fixed by our Abhishek. The last known change I know of was work I did on
> HBASE-18786 to remove some dodgy exception handling (prefer aborts to
> silent data corruption). Is this enough to move the stable pointer?
> According to our testing at Salesforce, yes, so far. We have yet to run in
> full production. Give us a few months of that and my answer will be
> unconditional one way or another. According to some offline conversation
> with Mikhail and Gary, the answer is in fact no, they still have one hairy
> use case causing occasional problems that look like more of this, but that
> feedback predates HBASE-18771.{quote}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Status: Patch Available (was: Open) > 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 > > Attachments: HBASE-18495.patch, HBASE-18945_2.patch > > > 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. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-13346) Clean up Filter package for post 1.0 s/KeyValue/Cell/g
[
https://issues.apache.org/jira/browse/HBASE-13346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199069#comment-16199069
]
stack commented on HBASE-13346:
---
Porting +1 from rb.
Chatting w/ [~psomogyi] , he suggests a rebase is needed given the filter
reverts that happened in last day or so. Otherwise, ok to commit [~psomogyi]?
It won't mess up your filter revert/redo project?
> Clean up Filter package for post 1.0 s/KeyValue/Cell/g
> --
>
> Key: HBASE-13346
> URL: https://issues.apache.org/jira/browse/HBASE-13346
> Project: HBase
> Issue Type: Bug
> Components: API, Filters
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Tamas Penzes
>Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-13346.master.001.patch,
> HBASE-13346.master.002.patch, HBASE-13346.master.003.patch,
> HBASE-13346.master.003.patch, HBASE-13346.master.004.patch,
> HBASE-13346.master.005.patch
>
>
> Since we have a bit of a messy Filter API with KeyValue vs Cell reference
> mixed up all over the place, I recommend cleaning this up once and for all.
> There should be no {{KeyValue}} (or {{kv}}, {{kvs}} etc.) in any method or
> parameter name.
> This includes deprecating and renaming filters too, for example
> {{FirstKeyOnlyFilter}}, which really should be named {{FirstKeyValueFilter}}
> as it does _not_ just return the key, but the entire cell. It should be
> deprecated and renamed to {{FirstCellFilter}} (or {{FirstColumnFilter}} if
> you prefer).
> In general we should clarify and settle on {{KeyValue}} vs {{Cell}} vs
> {{Column}} in our naming. The latter two are the only ones going forward with
> the public API, and are used synonymous. We should carefully check which is
> better suited (is it really a specific cell, or the newest cell, aka the
> newest column value) and settle on a naming schema.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18797) Deprecate Filter#filterKeyValue and add Filter#filterCell
[ https://issues.apache.org/jira/browse/HBASE-18797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199071#comment-16199071 ] stack commented on HBASE-18797: --- ping [~tamaas]. What you reckon for this one sir. > Deprecate Filter#filterKeyValue and add Filter#filterCell > - > > Key: HBASE-18797 > URL: https://issues.apache.org/jira/browse/HBASE-18797 > Project: HBase > Issue Type: Sub-task > Components: API, Filters >Reporter: Abhishek Singh Chouhan >Assignee: Tamas Penzes >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > Part of filter package cleanup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-18797) Deprecate Filter#filterKeyValue and add Filter#filterCell
[ https://issues.apache.org/jira/browse/HBASE-18797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes resolved HBASE-18797. -- Resolution: Duplicate Release Note: Since, the patch is added to the parent, this one should be closed > Deprecate Filter#filterKeyValue and add Filter#filterCell > - > > Key: HBASE-18797 > URL: https://issues.apache.org/jira/browse/HBASE-18797 > Project: HBase > Issue Type: Sub-task > Components: API, Filters >Reporter: Abhishek Singh Chouhan >Assignee: Tamas Penzes >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > Part of filter package cleanup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18797) Deprecate Filter#filterKeyValue and add Filter#filterCell
[ https://issues.apache.org/jira/browse/HBASE-18797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199080#comment-16199080 ] Tamas Penzes commented on HBASE-18797: -- Since, the patch is added to the parent, this one should be closed > Deprecate Filter#filterKeyValue and add Filter#filterCell > - > > Key: HBASE-18797 > URL: https://issues.apache.org/jira/browse/HBASE-18797 > Project: HBase > Issue Type: Sub-task > Components: API, Filters >Reporter: Abhishek Singh Chouhan >Assignee: Tamas Penzes >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > Part of filter package cleanup. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Resolved] (HBASE-15175) Add support for checkAndXX methods in JavaHBaseContext for Spark
[ https://issues.apache.org/jira/browse/HBASE-15175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu resolved HBASE-15175. Resolution: Won't Fix No traction. > Add support for checkAndXX methods in JavaHBaseContext for Spark > > > Key: HBASE-15175 > URL: https://issues.apache.org/jira/browse/HBASE-15175 > Project: HBase > Issue Type: Improvement > Components: spark >Reporter: Ted Yu > > Currently JavaHBaseContext has methods for bulkPut, bulkDelete, etc > It is desirable to add support for checkAndPut, checkAndMutate, > checkAndDelete as well. > See related thread: > http://search-hadoop.com/m/YGbbt3Szd24Vtpr&subj=Re+HBase+atomic+update > Thanks [~zzhan] for offline discussion -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18873) Hide protobufs in GlobalQuotaSettings
[ https://issues.apache.org/jira/browse/HBASE-18873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199101#comment-16199101 ] Josh Elser commented on HBASE-18873: [~mdrob], yeah, still something on my radar. Admittedly haven't started it yet, but am hoping to today. > Hide protobufs in GlobalQuotaSettings > - > > Key: HBASE-18873 > URL: https://issues.apache.org/jira/browse/HBASE-18873 > Project: HBase > Issue Type: Sub-task >Reporter: Josh Elser >Assignee: Josh Elser >Priority: Critical > Fix For: 2.0.0-alpha-4 > > > HBASE-18807 cleaned up direct protobuf use in the Coprocessor APIs for > quota-related functions. However, one new POJO introduced to hide these > protocol buffers still exposes PBs via some methods. > We should try to hide those as well. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
