[jira] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198210#comment-16198210
]
Hadoop QA commented on HBASE-12260:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
57s{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
1s{color} | {color:green} The patch appears to include 42 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 1m
4s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 8m
9s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
51s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m
36s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 2m
14s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 12m
39s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 9m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
13s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
19s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
56s{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
55s{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 27s{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
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
34s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
55s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}100m 27s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
33s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m
32s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m
0s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}205m 1s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestSplitLogWorker |
| | hadoop.hbase.master.TestSplitLogManager |
| | hadoop.hbase.master.TestAssignmentListener |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-12260 |
| JIRA Patch URL |
[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=16198198#comment-16198198 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-1.4 #946 (See [https://builds.apache.org/job/HBase-1.4/946/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 171cb0f174872766ace2dc8a4ac8ce9941f86e56) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [Commented] (HBASE-17678) FilterList with MUST_PASS_ONE may lead to redundant cells returned
[
https://issues.apache.org/jira/browse/HBASE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198199#comment-16198199
]
Hudson commented on HBASE-17678:
FAILURE: Integrated in Jenkins build HBase-1.4 #946 (See
[https://builds.apache.org/job/HBase-1.4/946/])
Revert "HBASE-17678 FilterList with MUST_PASS_ONE may lead to redundant
(busbey: rev 968eea84ad71aa6b285361f106f7293aa5191e98)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValueUtil.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
> FilterList with MUST_PASS_ONE may lead to redundant cells returned
> --
>
> Key: HBASE-17678
> URL: https://issues.apache.org/jira/browse/HBASE-17678
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
> Environment: RedHat 7.x
>Reporter: Jason Tokayer
>Assignee: Zheng Hu
> Fix For: HBASE-18410
>
> Attachments: HBASE-17678.addendum.patch, HBASE-17678.addendum.patch,
> HBASE-17678.branch-1.1.v1.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.1.v2.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.v1.patch, HBASE-17678.branch-1.v1.patch,
> HBASE-17678.branch-1.v2.patch, HBASE-17678.branch-1.v2.patch,
> HBASE-17678.v1.patch, HBASE-17678.v1.rough.patch, HBASE-17678.v2.patch,
> HBASE-17678.v3.patch, HBASE-17678.v4.patch, HBASE-17678.v4.patch,
> HBASE-17678.v5.patch, HBASE-17678.v6.patch, HBASE-17678.v7.patch,
> HBASE-17678.v7.patch, TestColumnPaginationFilterDemo.java
>
>
> When combining ColumnPaginationFilter with a single-element filterList,
> MUST_PASS_ONE and MUST_PASS_ALL give different results when there are
> multiple cells with the same timestamp. This is unexpected since there is
> only a single filter in the list, and I would believe that MUST_PASS_ALL and
> MUST_PASS_ONE should only affect the behavior of the joined filter and not
> the behavior of any one of the individual filters. If this is not a bug then
> it would be nice if the documentation is updated to explain this nuanced
> behavior.
> I know that there was a decision made in an earlier Hbase version to keep
> multiple cells with the same timestamp. This is generally fine but presents
> an issue when using the aforementioned filter combination.
> Steps to reproduce:
> In the shell create a table and insert some data:
> {code:none}
> create 'ns:tbl',{NAME => 'family',VERSIONS => 100}
> put 'ns:tbl','row','family:name','John',1
> put 'ns:tbl','row','family:name','Jane',1
> put 'ns:tbl','row','family:name','Gil',1
> put 'ns:tbl','row','family:name','Jane',1
> {code}
> Then, use a Scala client as:
> {code:none}
> import org.apache.hadoop.hbase.filter._
> import org.apache.hadoop.hbase.util.Bytes
> import org.apache.hadoop.hbase.client._
> import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName}
> import scala.collection.mutable._
> val config = HBaseConfiguration.create()
> config.set("hbase.zookeeper.quorum", "localhost")
> config.set("hbase.zookeeper.property.clientPort", "2181")
> val connection = ConnectionFactory.createConnection(config)
> val logicalOp = FilterList.Operator.MUST_PASS_ONE
> val limit = 1
> var resultsList = ListBuffer[String]()
> for (offset <- 0 to 20 by limit) {
> val table = connection.getTable(TableName.valueOf("ns:tbl"))
> val paginationFilter = new ColumnPaginationFilter(limit,offset)
> val filterList: FilterList = new FilterList(logicalOp,paginationFilter)
> println("@ filterList = "+filterList)
> val results = table.get(new
> Get(Bytes.toBytes("row")).setFilter(filterList))
> val cells = results.rawCells()
> if (cells != null) {
> for (cell <- cells) {
> val value = new String(CellUtil.cloneValue(cell))
> val qualifier = new String(CellUtil.cloneQualifier(cell))
> val family = new String(CellUtil.cloneFamily(cell))
> val result = "OFFSET = "+offset+":"+family + "," + qualifier
> + "," + value + "," + cell.getTimestamp()
> resultsList.append(result)
> }
> }
> }
> resultsList.foreach(println)
> {code}
> Here are the results for different limit and logicalOp settings:
> {code:none}
> Limit = 1 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 1 & logicalOp = MUST_PASS_ONE:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> OFFSET = 1:family,name,Gil,1
> OFFSET = 2:family,name,Jane,1
> OFFSET =
[jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
[ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198180#comment-16198180 ] stack commented on HBASE-18703: --- Below is a bit of a reply. bq. Other path is very high level, generic, row processing mechanism. And is only supposed to invoke right RowProcessors steps at right time. Yes bq. Other path is very high level, generic, row processing mechanism. And is only supposed to invoke right RowProcessors steps at right time. ... all well and good but there should also be one mutation path only, not two. bq. So if RowProcessor is more generic, shouldn't we move to it? Why move to an option which is the limited one. We shoudn't move to it because it is (mostly) unused, unknown (years after its original intro), incomplete, lagging in updates, and it doesn't support CPs. Nor do we need a generic engine at this point (we have limited API -- we'd not be able to exploit the general facility -- and if you want more in absence of RP, write yourself a Coprocessor Endpoint). We want a purposed code path by the time we land inside Region. The variants are currently such that core ops in Region are inscrutable. We can't have that. A project to refactor sounds grand. Its all internal Private classes so could happen anytime. Would like to start over though if we were going to do this rather than try and hack around a bit of stale, RP code written w/ a motive now years old. > Inconsistent behavior for preBatchMutate in doMiniBatchMutate and > processRowsWithLocks > -- > > Key: HBASE-18703 > URL: https://issues.apache.org/jira/browse/HBASE-18703 > Project: HBase > Issue Type: Bug > Components: Coprocessors >Reporter: Duo Zhang >Assignee: Umesh Agashe >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18703.master.001.patch, > hbase-18703.master.002.patch, hbase-18703.master.003.patch, > hbase-18703.master.004.patch, hbase-18703.master.005.patch, > hbase-18703.master.005.patch, hbase-18703.master.005.patch, > hbase-18703.master.006.patch, hbase-18703.master.007.patch > > > In doMiniBatchMutate, the preBatchMutate is called before building WAL, but > in processRowsWithLocks, we suggest the RowProcessor implementation to build > WAL in process method, which is ahead of preBatchMutate. > If a CP modifies the mutations, especially if it removes some cells from the > mutations, then the behavior of processRowsWithLocks is broken. The changes > applied to memstore and WAL will be different. And there is no way to remove > entries from a WALEdit through CP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-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=16198177#comment-16198177 ] ramkrishna.s.vasudevan commented on HBASE-18946: [~huaxiang] I tried your fix by adding the default regions to the beginning of the list passed to AM. But still this issue seems to occur. I had a doubt with the LB and how the region replica awareness is passed on to the LB. Am reading that code to understand. will be back here. > Stochastic load balancer assigns replica regions to the same RS > --- > > Key: HBASE-18946 > URL: https://issues.apache.org/jira/browse/HBASE-18946 > Project: HBase > Issue Type: Bug >Affects Versions: 2.0.0-alpha-3 >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-beta-1 > > Attachments: TestRegionReplicasWithRestartScenarios.java > > > Trying out region replica and its assignment I can see that some times the > default LB Stocahstic load balancer assigns replica regions to the same RS. > This happens when we have 3 RS checked in and we have a table with 3 > replicas. When a RS goes down then the replicas being assigned to same RS is > acceptable but the case when we have enough RS to assign this behaviour is > undesirable and does not solve the purpose of replicas. > [~huaxiang] and [~enis]. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198169#comment-16198169 ] ramkrishna.s.vasudevan commented on HBASE-18945: bq.That is really weird...If avoiding the large patch is primary condition, CoprocessorCellComparator for an interface is not right IMO. I thought CellComparator which is implemented and used every where seems to be a type of some comparator which is only for Coprocessors? So if we go with bigger patch only - any suggestions for the interface and impl class name? > 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-18975) B hadoop3 incompatibility
[
https://issues.apache.org/jira/browse/HBASE-18975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-18975:
--
Attachment: HBASE-18975-v2.patch
[~te...@apache.org], can you try v2 and attach log file? I added some tracing
> B 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] [Comment Edited] (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=16198154#comment-16198154 ] stack edited comment on HBASE-18951 at 10/10/17 4:35 AM: - Thanks. Patch LGTM. If no qualifier, it goes into RequestCoverter#buildCondition... which looks to be doing the decent thing. was (Author: stack): Thanks. Patch LGTM. > 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-beta-1 > > 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-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=16198155#comment-16198155 ] Ted Yu commented on HBASE-15410: Test added by HBASE-18957 is about MUST_PASS_ONE. This optimization is about MUST_PASS_ALL. I have run TestFilterListOnMini with patch v3 which passed. > 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=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-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=16198154#comment-16198154 ] stack commented on HBASE-18951: --- Thanks. Patch LGTM. > 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-beta-1 > > 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-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198152#comment-16198152 ] Sean Busbey commented on HBASE-18410: - the test for HBASE-18957 is now on all branches, but disabled on the feature branch for HBASE-18410. I marked fixVersion for those jiras that are on the feature branch to be HBASE-18410 so we can update them as needed when we get to merging. > 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] [Resolved] (HBASE-18904) Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
[
https://issues.apache.org/jira/browse/HBASE-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey resolved HBASE-18904.
-
Resolution: Fixed
Fix Version/s: (was: 2.0.0-alpha-4)
HBASE-18410
Currently fixed in the feature branch for HBASE-18410. If you'd like this
included in other release lines prior to us getting that branch merged back in
(and potentially backported to earlier versions) feel free to rebase onto
current master so long as the test from HBASE-18957 doesn't regress.
> Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
> ---
>
> Key: HBASE-18904
> URL: https://issues.apache.org/jira/browse/HBASE-18904
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Biju Nair
>Priority: Minor
> Fix For: HBASE-18410
>
> Attachments: HBASE-18904.PATCH
>
>
> Here is related code, around line 569:
> {code}
> if (isInReturnCodes(rc, ReturnCode.NEXT_ROW)) {
> return ReturnCode.NEXT_ROW;
> }
> case SEEK_NEXT_USING_HINT:
> {code}
> break was missing for the NEXT_ROW case.
--
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 ] Sean Busbey updated HBASE-15410: Fix Version/s: HBASE-18410 > 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=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] [Reopened] (HBASE-18904) Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
[
https://issues.apache.org/jira/browse/HBASE-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey reopened HBASE-18904:
-
> Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
> ---
>
> Key: HBASE-18904
> URL: https://issues.apache.org/jira/browse/HBASE-18904
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Biju Nair
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18904.PATCH
>
>
> Here is related code, around line 569:
> {code}
> if (isInReturnCodes(rc, ReturnCode.NEXT_ROW)) {
> return ReturnCode.NEXT_ROW;
> }
> case SEEK_NEXT_USING_HINT:
> {code}
> break was missing for the NEXT_ROW case.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18160) Fix incorrect logic in FilterList.filterKeyValue
[
https://issues.apache.org/jira/browse/HBASE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18160:
Resolution: Fixed
Fix Version/s: (was: 2.0.0-alpha-3)
(was: 1.3.2)
(was: 1.2.6)
(was: 1.4.0)
HBASE-18410
Status: Resolved (was: Patch Available)
Currently fixed in the feature branch for HBASE-18410. If you'd like this
included in other release lines prior to us getting that branch merged back in
(and potentially backported to earlier versions) feel free to rebase onto
current master so long as the test from HBASE-18957 doesn't regress.
> Fix incorrect logic in FilterList.filterKeyValue
> -
>
> Key: HBASE-18160
> URL: https://issues.apache.org/jira/browse/HBASE-18160
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: HBASE-18410
>
> Attachments: HBASE-18160.branch-1.3.v1.patch,
> HBASE-18160.branch-1.3.v1.patch, HBASE-18160.branch-1.4.v1.patch,
> HBASE-18160.branch-1.4.v1.patch, HBASE-18160.v1.patch, HBASE-18160.v2.patch,
> HBASE-18160.v2.patch, HBASE-18160.v3.patch, HBASE-18160.v4.patch,
> HBASE-18160.v5.patch, HBASE-18160.v6.patch, HBASE-18160.v6.patch,
> HBASE-18160.v7.patch, HBASE-18160.v8.patch, filter-and-map.txt,
> filter-or-map.txt
>
>
> As HBASE-17678 said, there are two problems in FilterList.filterKeyValue
> implementation:
> 1. FilterList did not consider INCLUDE_AND_SEEK_NEXT_ROW case( seems like
> INCLUDE_AND_SEEK_NEXT_ROW is a newly added case, and the dev forgot to
> consider FilterList), So if a user use INCLUDE_AND_SEEK_NEXT_ROW in his own
> Filter and wrapped by a FilterList, it'll throw an
> IllegalStateException("Received code is not valid.").
> 2. For FilterList with MUST_PASS_ONE, if filter-A in filter list return
> INCLUDE and filter-B in filter list return INCLUDE_AND_NEXT_COL, the
> FilterList will return INCLUDE_AND_NEXT_COL finally. According to the
> mininal step rule , It's incorrect. (filter list with MUST_PASS_ONE choose
> the mininal step among filters in filter list. Let's call it: The Mininal
> Step Rule).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18160) Fix incorrect logic in FilterList.filterKeyValue
[
https://issues.apache.org/jira/browse/HBASE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-18160:
Component/s: Filters
> Fix incorrect logic in FilterList.filterKeyValue
> -
>
> Key: HBASE-18160
> URL: https://issues.apache.org/jira/browse/HBASE-18160
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: HBASE-18410
>
> Attachments: HBASE-18160.branch-1.3.v1.patch,
> HBASE-18160.branch-1.3.v1.patch, HBASE-18160.branch-1.4.v1.patch,
> HBASE-18160.branch-1.4.v1.patch, HBASE-18160.v1.patch, HBASE-18160.v2.patch,
> HBASE-18160.v2.patch, HBASE-18160.v3.patch, HBASE-18160.v4.patch,
> HBASE-18160.v5.patch, HBASE-18160.v6.patch, HBASE-18160.v6.patch,
> HBASE-18160.v7.patch, HBASE-18160.v8.patch, filter-and-map.txt,
> filter-or-map.txt
>
>
> As HBASE-17678 said, there are two problems in FilterList.filterKeyValue
> implementation:
> 1. FilterList did not consider INCLUDE_AND_SEEK_NEXT_ROW case( seems like
> INCLUDE_AND_SEEK_NEXT_ROW is a newly added case, and the dev forgot to
> consider FilterList), So if a user use INCLUDE_AND_SEEK_NEXT_ROW in his own
> Filter and wrapped by a FilterList, it'll throw an
> IllegalStateException("Received code is not valid.").
> 2. For FilterList with MUST_PASS_ONE, if filter-A in filter list return
> INCLUDE and filter-B in filter list return INCLUDE_AND_NEXT_COL, the
> FilterList will return INCLUDE_AND_NEXT_COL finally. According to the
> mininal step rule , It's incorrect. (filter list with MUST_PASS_ONE choose
> the mininal step among filters in filter list. Let's call it: The Mininal
> Step Rule).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-17678) FilterList with MUST_PASS_ONE may lead to redundant cells returned
[
https://issues.apache.org/jira/browse/HBASE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Busbey updated HBASE-17678:
Resolution: Fixed
Fix Version/s: HBASE-18410
Status: Resolved (was: Patch Available)
marking as fixed in the feature branch for HBASE-18410. We can address a
backport after we're ready to merge to master with a fix for this issue that
doesn't also break HBASE-18957.
> FilterList with MUST_PASS_ONE may lead to redundant cells returned
> --
>
> Key: HBASE-17678
> URL: https://issues.apache.org/jira/browse/HBASE-17678
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
> Environment: RedHat 7.x
>Reporter: Jason Tokayer
>Assignee: Zheng Hu
> Fix For: HBASE-18410
>
> Attachments: HBASE-17678.addendum.patch, HBASE-17678.addendum.patch,
> HBASE-17678.branch-1.1.v1.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.1.v2.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.v1.patch, HBASE-17678.branch-1.v1.patch,
> HBASE-17678.branch-1.v2.patch, HBASE-17678.branch-1.v2.patch,
> HBASE-17678.v1.patch, HBASE-17678.v1.rough.patch, HBASE-17678.v2.patch,
> HBASE-17678.v3.patch, HBASE-17678.v4.patch, HBASE-17678.v4.patch,
> HBASE-17678.v5.patch, HBASE-17678.v6.patch, HBASE-17678.v7.patch,
> HBASE-17678.v7.patch, TestColumnPaginationFilterDemo.java
>
>
> When combining ColumnPaginationFilter with a single-element filterList,
> MUST_PASS_ONE and MUST_PASS_ALL give different results when there are
> multiple cells with the same timestamp. This is unexpected since there is
> only a single filter in the list, and I would believe that MUST_PASS_ALL and
> MUST_PASS_ONE should only affect the behavior of the joined filter and not
> the behavior of any one of the individual filters. If this is not a bug then
> it would be nice if the documentation is updated to explain this nuanced
> behavior.
> I know that there was a decision made in an earlier Hbase version to keep
> multiple cells with the same timestamp. This is generally fine but presents
> an issue when using the aforementioned filter combination.
> Steps to reproduce:
> In the shell create a table and insert some data:
> {code:none}
> create 'ns:tbl',{NAME => 'family',VERSIONS => 100}
> put 'ns:tbl','row','family:name','John',1
> put 'ns:tbl','row','family:name','Jane',1
> put 'ns:tbl','row','family:name','Gil',1
> put 'ns:tbl','row','family:name','Jane',1
> {code}
> Then, use a Scala client as:
> {code:none}
> import org.apache.hadoop.hbase.filter._
> import org.apache.hadoop.hbase.util.Bytes
> import org.apache.hadoop.hbase.client._
> import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName}
> import scala.collection.mutable._
> val config = HBaseConfiguration.create()
> config.set("hbase.zookeeper.quorum", "localhost")
> config.set("hbase.zookeeper.property.clientPort", "2181")
> val connection = ConnectionFactory.createConnection(config)
> val logicalOp = FilterList.Operator.MUST_PASS_ONE
> val limit = 1
> var resultsList = ListBuffer[String]()
> for (offset <- 0 to 20 by limit) {
> val table = connection.getTable(TableName.valueOf("ns:tbl"))
> val paginationFilter = new ColumnPaginationFilter(limit,offset)
> val filterList: FilterList = new FilterList(logicalOp,paginationFilter)
> println("@ filterList = "+filterList)
> val results = table.get(new
> Get(Bytes.toBytes("row")).setFilter(filterList))
> val cells = results.rawCells()
> if (cells != null) {
> for (cell <- cells) {
> val value = new String(CellUtil.cloneValue(cell))
> val qualifier = new String(CellUtil.cloneQualifier(cell))
> val family = new String(CellUtil.cloneFamily(cell))
> val result = "OFFSET = "+offset+":"+family + "," + qualifier
> + "," + value + "," + cell.getTimestamp()
> resultsList.append(result)
> }
> }
> }
> resultsList.foreach(println)
> {code}
> Here are the results for different limit and logicalOp settings:
> {code:none}
> Limit = 1 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 1 & logicalOp = MUST_PASS_ONE:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> OFFSET = 1:family,name,Gil,1
> OFFSET = 2:family,name,Jane,1
> OFFSET = 3:family,name,John,1
> Limit = 2 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 2 & logicalOp = MUST_PASS_ONE:
> scala>
[jira] [Updated] (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 ma
[ https://issues.apache.org/jira/browse/HBASE-18957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18957: Resolution: Fixed Status: Resolved (was: Patch Available) > 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] [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=16198144#comment-16198144 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-1.2-JDK7 #234 (See [https://builds.apache.org/job/HBase-1.2-JDK7/234/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev bd63eb73cd80b3b06111d4ade7556516614958c8) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [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=16198143#comment-16198143 ] Hudson commented on HBASE-18957: SUCCESS: Integrated in Jenkins build HBase-1.2-IT #967 (See [https://builds.apache.org/job/HBase-1.2-IT/967/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev bd63eb73cd80b3b06111d4ade7556516614958c8) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [Created] (HBASE-18977) Reenable test of filterlist using MUST_PASS_ONE and two familyfilters
Sean Busbey created HBASE-18977: --- Summary: Reenable test of filterlist using MUST_PASS_ONE and two familyfilters Key: HBASE-18977 URL: https://issues.apache.org/jira/browse/HBASE-18977 Project: HBase Issue Type: Sub-task Components: Filters Affects Versions: HBASE-18410 Reporter: Sean Busbey Priority: Blocker Fix For: HBASE-18410 The HBASE-18410 feature branch started with the test from HBASE-18957 disabled. we need to enable it before merging. -- 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=16198141#comment-16198141 ] Duo Zhang commented on HBASE-18951: --- In this patch you can not pass null for a qualifier, but you can choose to not specify a qualifier, i.e, not call the method. This is intentional as I want to avoid nullable parameters in the AsyncTable API. > 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-beta-1 > > 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] [Updated] (HBASE-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18410: Component/s: Filters > 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-18410) FilterList Improvement.
[ https://issues.apache.org/jira/browse/HBASE-18410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-18410: Fix Version/s: (was: 2.0.0-alpha-4) 2.0.0-beta-1 > 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-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=16198139#comment-16198139 ] stack commented on HBASE-18951: --- I'm not being of much help. Feel fine to ignore my questions. I don't see Nullable in the patch. You talking about not being able to pass null for a qualifier? > 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-beta-1 > > 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-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=16198136#comment-16198136 ] Duo Zhang commented on HBASE-18957: --- OK, got it. [~openinx] FYI. > 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] [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=16198134#comment-16198134 ] Hudson commented on HBASE-18957: SUCCESS: Integrated in Jenkins build HBase-1.3-IT #227 (See [https://builds.apache.org/job/HBase-1.3-IT/227/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 0d8f9683b1c0ac7fe1fe350d576c8c72a83791ff) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [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=16198132#comment-16198132 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-1.3-JDK8 #313 (See [https://builds.apache.org/job/HBase-1.3-JDK8/313/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 0d8f9683b1c0ac7fe1fe350d576c8c72a83791ff) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [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=16198131#comment-16198131
]
Mikhail Antonov commented on HBASE-18397:
-
[~apurtell] I'm considering lowering the priority of this jira due to the fact
that it hasn't been reproduced recently and I don't seem to see lots of people
complaining about it. What do you think?
> 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-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=16198133#comment-16198133 ] Sean Busbey commented on HBASE-18957: - bq. OK, seems the decision is to revert to the first place and fix FilterList in a feature branch? Can we get this down before 2.0.0 release? I think this is important and not a 'feature' but a bug? I'm hopeful this will get done in time for the 2.0.0-beta-1 release, FWIW. I use "feature branch" just because it's a git term-of-art, not because I think any of these things are necessarily features rather than bugs. > 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] [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=16198130#comment-16198130 ] Sean Busbey commented on HBASE-18957: - when I'm done pushing branches those fixes will all be on a feature branch for HBASE-18410. When we can pass the test added here, we'll be ready to merge. I'm happy to add whichever patches to branches other than the feature branch in the mean time, so long as we don't introduce new regressions. The reviews on HBASE-18368 and related changes seemed bogged down in the current complexity of the implementation. I figure giving ourselves a space to get the refactoring and clean up work described in HBASE-18410's subtasks in place will make it easier for folks to come to decisions. > 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] [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=16198127#comment-16198127 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-1.3-JDK7 #299 (See [https://builds.apache.org/job/HBase-1.3-JDK7/299/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 0d8f9683b1c0ac7fe1fe350d576c8c72a83791ff) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [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=16198125#comment-16198125 ] Duo Zhang commented on HBASE-18957: --- OK, seems the decision is to revert to the first place and fix FilterList in a feature branch? Can we get this down before 2.0.0 release? I think this is important and not a 'feature' but a bug? > 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] [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=16198123#comment-16198123 ] Chia-Ping Tsai commented on HBASE-18951: Lack of qualifier is legal to our data model, but we don’t say how to get/set data w/o qualifier. The Increment op doesn’t even accept null qualifier before HBASE-15616. +1 to use empty array. > 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-beta-1 > > 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-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=16198118#comment-16198118 ] Duo Zhang commented on HBASE-18957: --- The commits you reverted aim to fix other strange behaviors. IIRC, in a FilterList with OR, if one filter returns NEXT_COLUMN and another returns INCLUDE, is it valid to still passes the cells from same column to the filter which returns NEXT_COLUMN? And for now, NEXT_ROW is ambiguous as a filter will be shared across multiple StoreScanners, and we will only bypass the current family when NEXT_ROW , so a filter can still receive the cells from the same row but another family. How do we want to solve this problem? Thanks. > 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] [Commented] (HBASE-17255) Backport HBASE-17181 to branch-1.2
[ https://issues.apache.org/jira/browse/HBASE-17255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198119#comment-16198119 ] Mikhail Antonov commented on HBASE-17255: - Yep this should go to 1.3 as well. > Backport HBASE-17181 to branch-1.2 > -- > > Key: HBASE-17255 > URL: https://issues.apache.org/jira/browse/HBASE-17255 > Project: HBase > Issue Type: Task > Components: Thrift >Affects Versions: 1.2.3 >Reporter: Jian Yi >Assignee: Jian Yi >Priority: Minor > Fix For: 1.2.5 > > Attachments: HBASE-17225-branch-1.2-V1.patch, > HBASE-17225-branch-1.2-V1.patch > > > Let HBase thrift2 support TThreadedSelectorServer -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18935) Backport bug fixes which were fixed in 1.2.x and 1.4.x versions but not in 1.3.x version
[ https://issues.apache.org/jira/browse/HBASE-18935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198115#comment-16198115 ] Mikhail Antonov commented on HBASE-18935: - Thanks for opening backport jiras! I also think that opening new jiras is better than reopening old ones. The only thought I have is that is would be nice to incluse the headline of the original jira into the head line, and not just "Backport HBASE-16870 to branch-1.3", this will make the titles longer but the actual content would be easily seen, what the jira is about, when preparing release notes and such, where here people need to manually go lookup the referenced jira to get the title. > Backport bug fixes which were fixed in 1.2.x and 1.4.x versions but not in > 1.3.x version > > > Key: HBASE-18935 > URL: https://issues.apache.org/jira/browse/HBASE-18935 > Project: HBase > Issue Type: Umbrella >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > > Backport the bug fixes which were fixed in 1.2.x and 1.4.x branch but missed > in 1.3.x branch. > I have used the below query to those jiras. > *project = HBASE AND status in (Resolved, Closed) AND fixVersion in (1.4.0, > 1.4.1) AND fixVersion in (1.2.7, 1.2.0, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.2.5, > 1.2.6) AND fixVersion not in (1.3.0, 1.3.1, 1.3.2)* -- 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=16198114#comment-16198114 ] Jingcheng Du commented on HBASE-18693: -- Thanks a lot [~huaxiang], I've updated the comments in RB. > 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-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=16198110#comment-16198110
]
Sean Busbey commented on HBASE-18957:
-
{quote}
I skimmed all the related issues and didn't find out what is the final behavior
we all agree with. Can you guys please add a clear description of what the
expected behavior is in the description?
{quote}
The description already has:
{quote}
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.
{quote}
what kind of detail would you like added?
> 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] [Commented] (HBASE-17678) FilterList with MUST_PASS_ONE may lead to redundant cells returned
[
https://issues.apache.org/jira/browse/HBASE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198108#comment-16198108
]
Hudson commented on HBASE-17678:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3859/])
Revert "HBASE-17678 FilterList with MUST_PASS_ONE lead to redundancy (busbey:
rev f97c0bd8b55a09875dd94a32d8785dcf1944ea5c)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
Revert "HBASE-17678 FilterList with MUST_PASS_ONE may lead to redundant
(busbey: rev b727ab850cbabcc480d5ede2f1970e896e6f3e46)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> FilterList with MUST_PASS_ONE may lead to redundant cells returned
> --
>
> Key: HBASE-17678
> URL: https://issues.apache.org/jira/browse/HBASE-17678
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
> Environment: RedHat 7.x
>Reporter: Jason Tokayer
>Assignee: Zheng Hu
> Attachments: HBASE-17678.addendum.patch, HBASE-17678.addendum.patch,
> HBASE-17678.branch-1.1.v1.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.1.v2.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.v1.patch, HBASE-17678.branch-1.v1.patch,
> HBASE-17678.branch-1.v2.patch, HBASE-17678.branch-1.v2.patch,
> HBASE-17678.v1.patch, HBASE-17678.v1.rough.patch, HBASE-17678.v2.patch,
> HBASE-17678.v3.patch, HBASE-17678.v4.patch, HBASE-17678.v4.patch,
> HBASE-17678.v5.patch, HBASE-17678.v6.patch, HBASE-17678.v7.patch,
> HBASE-17678.v7.patch, TestColumnPaginationFilterDemo.java
>
>
> When combining ColumnPaginationFilter with a single-element filterList,
> MUST_PASS_ONE and MUST_PASS_ALL give different results when there are
> multiple cells with the same timestamp. This is unexpected since there is
> only a single filter in the list, and I would believe that MUST_PASS_ALL and
> MUST_PASS_ONE should only affect the behavior of the joined filter and not
> the behavior of any one of the individual filters. If this is not a bug then
> it would be nice if the documentation is updated to explain this nuanced
> behavior.
> I know that there was a decision made in an earlier Hbase version to keep
> multiple cells with the same timestamp. This is generally fine but presents
> an issue when using the aforementioned filter combination.
> Steps to reproduce:
> In the shell create a table and insert some data:
> {code:none}
> create 'ns:tbl',{NAME => 'family',VERSIONS => 100}
> put 'ns:tbl','row','family:name','John',1
> put 'ns:tbl','row','family:name','Jane',1
> put 'ns:tbl','row','family:name','Gil',1
> put 'ns:tbl','row','family:name','Jane',1
> {code}
> Then, use a Scala client as:
> {code:none}
> import org.apache.hadoop.hbase.filter._
> import org.apache.hadoop.hbase.util.Bytes
> import org.apache.hadoop.hbase.client._
> import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName}
> import scala.collection.mutable._
> val config = HBaseConfiguration.create()
> config.set("hbase.zookeeper.quorum", "localhost")
> config.set("hbase.zookeeper.property.clientPort", "2181")
> val connection = ConnectionFactory.createConnection(config)
> val logicalOp = FilterList.Operator.MUST_PASS_ONE
> val limit = 1
> var resultsList = ListBuffer[String]()
> for (offset <- 0 to 20 by limit) {
> val table = connection.getTable(TableName.valueOf("ns:tbl"))
> val paginationFilter = new ColumnPaginationFilter(limit,offset)
> val filterList: FilterList = new FilterList(logicalOp,paginationFilter)
> println("@ filterList = "+filterList)
> val results = table.get(new
> Get(Bytes.toBytes("row")).setFilter(filterList))
> val cells = results.rawCells()
> if (cells != null) {
> for (cell <- cells) {
> val value = new String(CellUtil.cloneValue(cell))
> val qualifier = new String(CellUtil.cloneQualifier(cell))
> val family = new String(CellUtil.cloneFamily(cell))
> val result = "OFFSET = "+offset+":"+family + "," + qualifier
> + "," + value + "," + cell.getTimestamp()
> resultsList.append(result)
> }
> }
> }
> resultsList.foreach(println)
> {code}
> Here are the results for different limit and logicalOp settings:
> {code:none}
> Limit = 1 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 1 & logicalOp = MUST_PASS_ONE:
> scala> resultsList.foreach(println)
> OFFSET =
[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=16198107#comment-16198107 ] Hudson commented on HBASE-15410: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3859/]) Revert "HBASE-15410 Utilize the max seek value when all Filters in (busbey: rev 4eea0d923e37180b25d89db676aed2f699f5e0ba) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java > 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 > > 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=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-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=16198103#comment-16198103 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3859/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 9cabf34e7bd9bdd85920f5cd3bdfe5a331166ec4) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [Commented] (HBASE-18160) Fix incorrect logic in FilterList.filterKeyValue
[
https://issues.apache.org/jira/browse/HBASE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198105#comment-16198105
]
Hudson commented on HBASE-18160:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3859/])
Revert "HBASE-18160 Fix incorrect logic in FilterList.filterKeyValue" (busbey:
rev 183b3e31bd6255cb7b1e312f37a06fb60d7f21d7)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> Fix incorrect logic in FilterList.filterKeyValue
> -
>
> Key: HBASE-18160
> URL: https://issues.apache.org/jira/browse/HBASE-18160
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 1.4.0, 1.2.6, 1.3.2, 2.0.0-alpha-3
>
> Attachments: HBASE-18160.branch-1.3.v1.patch,
> HBASE-18160.branch-1.3.v1.patch, HBASE-18160.branch-1.4.v1.patch,
> HBASE-18160.branch-1.4.v1.patch, HBASE-18160.v1.patch, HBASE-18160.v2.patch,
> HBASE-18160.v2.patch, HBASE-18160.v3.patch, HBASE-18160.v4.patch,
> HBASE-18160.v5.patch, HBASE-18160.v6.patch, HBASE-18160.v6.patch,
> HBASE-18160.v7.patch, HBASE-18160.v8.patch, filter-and-map.txt,
> filter-or-map.txt
>
>
> As HBASE-17678 said, there are two problems in FilterList.filterKeyValue
> implementation:
> 1. FilterList did not consider INCLUDE_AND_SEEK_NEXT_ROW case( seems like
> INCLUDE_AND_SEEK_NEXT_ROW is a newly added case, and the dev forgot to
> consider FilterList), So if a user use INCLUDE_AND_SEEK_NEXT_ROW in his own
> Filter and wrapped by a FilterList, it'll throw an
> IllegalStateException("Received code is not valid.").
> 2. For FilterList with MUST_PASS_ONE, if filter-A in filter list return
> INCLUDE and filter-B in filter list return INCLUDE_AND_NEXT_COL, the
> FilterList will return INCLUDE_AND_NEXT_COL finally. According to the
> mininal step rule , It's incorrect. (filter list with MUST_PASS_ONE choose
> the mininal step among filters in filter list. Let's call it: The Mininal
> Step Rule).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18904) Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
[
https://issues.apache.org/jira/browse/HBASE-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198104#comment-16198104
]
Hudson commented on HBASE-18904:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3859/])
Revert "HBASE-18904 Missing break in NEXT_ROW case of (busbey: rev
e8fa9cc85f708d8866fdff7b7a502fdeefc8f0d4)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
> Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
> ---
>
> Key: HBASE-18904
> URL: https://issues.apache.org/jira/browse/HBASE-18904
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Biju Nair
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18904.PATCH
>
>
> Here is related code, around line 569:
> {code}
> if (isInReturnCodes(rc, ReturnCode.NEXT_ROW)) {
> return ReturnCode.NEXT_ROW;
> }
> case SEEK_NEXT_USING_HINT:
> {code}
> break was missing for the NEXT_ROW case.
--
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=16198102#comment-16198102
]
Hudson commented on HBASE-18842:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3859 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3859/])
HBASE-18842 Fix unknown namespace message in clone_snapshot (jyates: rev
0ff4f5fba9cef8b4dea599357d935b47f6151152)
* (edit) hbase-shell/src/main/ruby/shell/commands/clone_snapshot.rb
* (edit) hbase-shell/src/test/ruby/shell/commands_test.rb
> 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] [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=16198101#comment-16198101 ] Mikhail Antonov commented on HBASE-18786: - [~apurtell] I'm going through the features to get 1.3.2 out in next few weeks. This has fixedVer 1.3.2 but I'm not seeing a commit here? > 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.3.2, 1.5.0 > > Attachments: 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-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=16198098#comment-16198098
]
Duo Zhang commented on HBASE-18951:
---
{quote}
Passing a null once was supposed to signal add the value to the family w/o a
qualifier (IIRC). This was not an especially good idea. Now we'd do it with a
qualifier that is zero-byte array?
{quote}
It seems that there is no difference between a null qualifier and an empty byte
array qualifier. Let me write a test to verify it.
{quote}
i.e. you'd do this inside the checkAndXXX?
if (qualifier == null)
{ qualifier = HConstants.EMPTY_BYTE_ARRAY; }
Thats seems good to me.
{quote}
Not in this patch. It is an implementation detail and can be changed at any
time. For now I think we need to focus on the public API. We should make the
breaking changes at once. Otherwise we need to carry them for another major
release...
> 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-beta-1
>
> 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-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198099#comment-16198099 ] Hudson commented on HBASE-18923: FAILURE: Integrated in Jenkins build HBase-1.5 #90 (See [https://builds.apache.org/job/HBase-1.5/90/]) HBASE-18923 TestTableResource flaky on branch-1 (apurtell: rev c48155a4d117d2d8f8f3f483763e616968b5a1a1) * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestTableResource.java > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-18923-branch-1-V2.patch, HBASE-18923-branch-1.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-17678) FilterList with MUST_PASS_ONE may lead to redundant cells returned
[
https://issues.apache.org/jira/browse/HBASE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198091#comment-16198091
]
Hudson commented on HBASE-17678:
FAILURE: Integrated in Jenkins build HBase-2.0 #658 (See
[https://builds.apache.org/job/HBase-2.0/658/])
Revert "HBASE-17678 FilterList with MUST_PASS_ONE lead to redundancy (busbey:
rev 852b5783841aeb2a55b9ec6dd7ef37b4f2269b1c)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
Revert "HBASE-17678 FilterList with MUST_PASS_ONE may lead to redundant
(busbey: rev 38e52bb29e173c0e47f29214618133e09cd5f96b)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> FilterList with MUST_PASS_ONE may lead to redundant cells returned
> --
>
> Key: HBASE-17678
> URL: https://issues.apache.org/jira/browse/HBASE-17678
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
> Environment: RedHat 7.x
>Reporter: Jason Tokayer
>Assignee: Zheng Hu
> Attachments: HBASE-17678.addendum.patch, HBASE-17678.addendum.patch,
> HBASE-17678.branch-1.1.v1.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.1.v2.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.v1.patch, HBASE-17678.branch-1.v1.patch,
> HBASE-17678.branch-1.v2.patch, HBASE-17678.branch-1.v2.patch,
> HBASE-17678.v1.patch, HBASE-17678.v1.rough.patch, HBASE-17678.v2.patch,
> HBASE-17678.v3.patch, HBASE-17678.v4.patch, HBASE-17678.v4.patch,
> HBASE-17678.v5.patch, HBASE-17678.v6.patch, HBASE-17678.v7.patch,
> HBASE-17678.v7.patch, TestColumnPaginationFilterDemo.java
>
>
> When combining ColumnPaginationFilter with a single-element filterList,
> MUST_PASS_ONE and MUST_PASS_ALL give different results when there are
> multiple cells with the same timestamp. This is unexpected since there is
> only a single filter in the list, and I would believe that MUST_PASS_ALL and
> MUST_PASS_ONE should only affect the behavior of the joined filter and not
> the behavior of any one of the individual filters. If this is not a bug then
> it would be nice if the documentation is updated to explain this nuanced
> behavior.
> I know that there was a decision made in an earlier Hbase version to keep
> multiple cells with the same timestamp. This is generally fine but presents
> an issue when using the aforementioned filter combination.
> Steps to reproduce:
> In the shell create a table and insert some data:
> {code:none}
> create 'ns:tbl',{NAME => 'family',VERSIONS => 100}
> put 'ns:tbl','row','family:name','John',1
> put 'ns:tbl','row','family:name','Jane',1
> put 'ns:tbl','row','family:name','Gil',1
> put 'ns:tbl','row','family:name','Jane',1
> {code}
> Then, use a Scala client as:
> {code:none}
> import org.apache.hadoop.hbase.filter._
> import org.apache.hadoop.hbase.util.Bytes
> import org.apache.hadoop.hbase.client._
> import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName}
> import scala.collection.mutable._
> val config = HBaseConfiguration.create()
> config.set("hbase.zookeeper.quorum", "localhost")
> config.set("hbase.zookeeper.property.clientPort", "2181")
> val connection = ConnectionFactory.createConnection(config)
> val logicalOp = FilterList.Operator.MUST_PASS_ONE
> val limit = 1
> var resultsList = ListBuffer[String]()
> for (offset <- 0 to 20 by limit) {
> val table = connection.getTable(TableName.valueOf("ns:tbl"))
> val paginationFilter = new ColumnPaginationFilter(limit,offset)
> val filterList: FilterList = new FilterList(logicalOp,paginationFilter)
> println("@ filterList = "+filterList)
> val results = table.get(new
> Get(Bytes.toBytes("row")).setFilter(filterList))
> val cells = results.rawCells()
> if (cells != null) {
> for (cell <- cells) {
> val value = new String(CellUtil.cloneValue(cell))
> val qualifier = new String(CellUtil.cloneQualifier(cell))
> val family = new String(CellUtil.cloneFamily(cell))
> val result = "OFFSET = "+offset+":"+family + "," + qualifier
> + "," + value + "," + cell.getTimestamp()
> resultsList.append(result)
> }
> }
> }
> resultsList.foreach(println)
> {code}
> Here are the results for different limit and logicalOp settings:
> {code:none}
> Limit = 1 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 1 & logicalOp = MUST_PASS_ONE:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> OFFSET =
[jira] [Commented] (HBASE-18160) Fix incorrect logic in FilterList.filterKeyValue
[
https://issues.apache.org/jira/browse/HBASE-18160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198089#comment-16198089
]
Hudson commented on HBASE-18160:
FAILURE: Integrated in Jenkins build HBase-2.0 #658 (See
[https://builds.apache.org/job/HBase-2.0/658/])
Revert "HBASE-18160 Fix incorrect logic in FilterList.filterKeyValue" (busbey:
rev 2dcdd13a01884dcd4176299aa45bd80079c675b2)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
> Fix incorrect logic in FilterList.filterKeyValue
> -
>
> Key: HBASE-18160
> URL: https://issues.apache.org/jira/browse/HBASE-18160
> Project: HBase
> Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 1.4.0, 1.2.6, 1.3.2, 2.0.0-alpha-3
>
> Attachments: HBASE-18160.branch-1.3.v1.patch,
> HBASE-18160.branch-1.3.v1.patch, HBASE-18160.branch-1.4.v1.patch,
> HBASE-18160.branch-1.4.v1.patch, HBASE-18160.v1.patch, HBASE-18160.v2.patch,
> HBASE-18160.v2.patch, HBASE-18160.v3.patch, HBASE-18160.v4.patch,
> HBASE-18160.v5.patch, HBASE-18160.v6.patch, HBASE-18160.v6.patch,
> HBASE-18160.v7.patch, HBASE-18160.v8.patch, filter-and-map.txt,
> filter-or-map.txt
>
>
> As HBASE-17678 said, there are two problems in FilterList.filterKeyValue
> implementation:
> 1. FilterList did not consider INCLUDE_AND_SEEK_NEXT_ROW case( seems like
> INCLUDE_AND_SEEK_NEXT_ROW is a newly added case, and the dev forgot to
> consider FilterList), So if a user use INCLUDE_AND_SEEK_NEXT_ROW in his own
> Filter and wrapped by a FilterList, it'll throw an
> IllegalStateException("Received code is not valid.").
> 2. For FilterList with MUST_PASS_ONE, if filter-A in filter list return
> INCLUDE and filter-B in filter list return INCLUDE_AND_NEXT_COL, the
> FilterList will return INCLUDE_AND_NEXT_COL finally. According to the
> mininal step rule , It's incorrect. (filter list with MUST_PASS_ONE choose
> the mininal step among filters in filter list. Let's call it: The Mininal
> Step Rule).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18904) Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
[
https://issues.apache.org/jira/browse/HBASE-18904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198088#comment-16198088
]
Hudson commented on HBASE-18904:
FAILURE: Integrated in Jenkins build HBase-2.0 #658 (See
[https://builds.apache.org/job/HBase-2.0/658/])
Revert "HBASE-18904 Missing break in NEXT_ROW case of (busbey: rev
3dd66e6cda4898ce381bc19d5830c0029992292f)
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
> Missing break in NEXT_ROW case of FilterList#mergeReturnCodeForOrOperator()
> ---
>
> Key: HBASE-18904
> URL: https://issues.apache.org/jira/browse/HBASE-18904
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Biju Nair
>Priority: Minor
> Fix For: 2.0.0-alpha-4
>
> Attachments: HBASE-18904.PATCH
>
>
> Here is related code, around line 569:
> {code}
> if (isInReturnCodes(rc, ReturnCode.NEXT_ROW)) {
> return ReturnCode.NEXT_ROW;
> }
> case SEEK_NEXT_USING_HINT:
> {code}
> break was missing for the NEXT_ROW case.
--
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=16198086#comment-16198086
]
stack commented on HBASE-18951:
---
Passing a null once was supposed to signal add the value to the family w/o a
qualifier (IIRC). This was not an especially good idea. Now we'd do it with a
qualifier that is zero-byte array? Does the user have to pass zero-length byte
array? Or will it be done for them by the builder; i.e. convert from null to
zero-length byte array.
i.e. you'd do this inside the checkAndXXX?
if (qualifier == null) {
qualifier = HConstants.EMPTY_BYTE_ARRAY;
}
Thats seems good to me.
> 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-beta-1
>
> 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-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=16198090#comment-16198090 ] Hudson commented on HBASE-15410: FAILURE: Integrated in Jenkins build HBase-2.0 #658 (See [https://builds.apache.org/job/HBase-2.0/658/]) Revert "HBASE-15410 Utilize the max seek value when all Filters in (busbey: rev 1d07c8eec48578c7b462811cf5ada15fd8c36e6b) * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java > 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 > > 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=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-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=16198087#comment-16198087 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-2.0 #658 (See [https://builds.apache.org/job/HBase-2.0/658/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 08aea43472e662cc23dfced74af9cfffa46b2081) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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-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: -- Attachment: HBASE-18951-v1.patch Modify comments. Add error message. > 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-beta-1 > > 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-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198083#comment-16198083 ] Hudson commented on HBASE-18923: SUCCESS: Integrated in Jenkins build HBase-1.4 #945 (See [https://builds.apache.org/job/HBase-1.4/945/]) HBASE-18923 TestTableResource flaky on branch-1 (apurtell: rev ab8b0a36624e294cc5d9690fde3fca796449b58c) * (edit) hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestTableResource.java > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-18923-branch-1-V2.patch, HBASE-18923-branch-1.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18939) Backport HBASE-16538 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198081#comment-16198081 ] Mikhail Antonov commented on HBASE-18939: - Thanks! I'm going to spin up 1.3.2 soon so this is the right time. > Backport HBASE-16538 to branch-1.3 > -- > > Key: HBASE-18939 > URL: https://issues.apache.org/jira/browse/HBASE-18939 > Project: HBase > Issue Type: Sub-task >Affects Versions: 1.3.1 >Reporter: Ashish Singhi >Assignee: Ashish Singhi > Fix For: 1.3.2 > > Attachments: HBASE-18939-branch-1.3.patch > > -- 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=16198079#comment-16198079
]
Mikhail Antonov commented on HBASE-18867:
-
+1 for 1.3. Compiling with Java 9 is good to have for 1.3 line
Thanks [~busbey]!
> 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] =
>
[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=16198075#comment-16198075 ] Duo Zhang commented on HBASE-18951: --- And also see CellUtil.matchingQualifier methods, if the byte array is null then we just check if the qualifier length of the given cell is 0. I haven't found a place where we treat null qualifier differently with an empty byte array. > 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-beta-1 > > Attachments: 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-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=16198074#comment-16198074
]
Hadoop QA commented on HBASE-18867:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 7m
33s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
54s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
31s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
21s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
46s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
53s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
24s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
46s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
22s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
22s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
19s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
20s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 23s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
41s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
21s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 7m 12s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 61m 51s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestInterfaceAudienceAnnotations |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b3a2a00 |
| JIRA Issue | HBASE-18867 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891190/HBASE-18867.branch-1.3.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit xml compile
|
| uname | Linux 79daa2679864 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision |
[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=16198072#comment-16198072 ] Duo Zhang commented on HBASE-18951: --- See Get.addColumn sir. > 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-beta-1 > > Attachments: 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-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=16198070#comment-16198070
]
Hadoop QA commented on HBASE-18867:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
22s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
49s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
21s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
19s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s{color} | {color:green} branch-1.3 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 7m
27s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
56s{color} | {color:green} branch-1.3 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
25s{color} | {color:green} branch-1.3 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
47s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
28s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
28s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
21s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
36s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
1s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
18s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 19s{color} | {color:green} Patch does not cause any errors with Hadoop
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
45s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m
24s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 7m 15s{color}
| {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
12s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 67m 40s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.TestInterfaceAudienceAnnotations |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18867 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891190/HBASE-18867.branch-1.3.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit xml compile
|
| uname | Linux 321f881b3426 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
|
| git revision |
[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=16198065#comment-16198065 ] stack commented on HBASE-18951: --- bq. So why not use an empty byte array directly and disable null qualifier? stack Anoop Sam John. Which methods? > 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-beta-1 > > Attachments: 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-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198066#comment-16198066 ] stack commented on HBASE-12260: --- .012 Fix test failure. > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-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=16198060#comment-16198060 ] Duo Zhang commented on HBASE-18951: --- I reviewed the related methods in Get, Scan, and Put, seems we always convert a null qualifier to an empty byte array. So why not use an empty byte array directly and disable null qualifier? [~stack] [~anoopsamjohn]. Thanks. > 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-beta-1 > > Attachments: 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-18906) Investigate Phoenix usages of Region#waitForXXX APIs
[ https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198057#comment-16198057 ] Duo Zhang commented on HBASE-18906: --- And for compaction, a problem is that if the compaction request is failed for some reason(for example, only one file in a Store) we give nothing to users. Need to add a new method to CompactionLifeCycleTracker I think. > Investigate Phoenix usages of Region#waitForXXX APIs > > > Key: HBASE-18906 > URL: https://issues.apache.org/jira/browse/HBASE-18906 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0-alpha-4 > > > While reviewing HBASE-18183, Andy pointed out that Phoenix uses > waitForFlushesAndCompactions and/or waitForFlushes for diff reasons. This > issue is to see why they need them and whether alternate ways are possible. > This seems to be too much internal stuff and a normal CP hook calling these > would be dangerous. > If there are alternate ways for Phoenix not to use this and not landing in > issues (As said by Andy) we should suggest/fix for them. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18906) Investigate Phoenix usages of Region#waitForXXX APIs
[
https://issues.apache.org/jira/browse/HBASE-18906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198053#comment-16198053
]
Duo Zhang commented on HBASE-18906:
---
{quote}
- Request flush async
- Request compaction async
- Poll for the completion of a single flush request
- Poll for the completion of a single compaction request
{quote}
So at least we need to provide these abilities. [~anoopsamjohn] so let's finish
HBASE-18183 and then start working on this? I think the patch of HBASE-18183
does not need to be perfect, it is big enough... Can polish in follow on issues.
Thanks.
> Investigate Phoenix usages of Region#waitForXXX APIs
>
>
> Key: HBASE-18906
> URL: https://issues.apache.org/jira/browse/HBASE-18906
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
>Reporter: Anoop Sam John
>Assignee: Anoop Sam John
> Fix For: 2.0.0-alpha-4
>
>
> While reviewing HBASE-18183, Andy pointed out that Phoenix uses
> waitForFlushesAndCompactions and/or waitForFlushes for diff reasons. This
> issue is to see why they need them and whether alternate ways are possible.
> This seems to be too much internal stuff and a normal CP hook calling these
> would be dangerous.
> If there are alternate ways for Phoenix not to use this and not landing in
> issues (As said by Andy) we should suggest/fix for them.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
[ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198045#comment-16198045 ] Appy commented on HBASE-18703: -- Catching up from the top. There has already been a lot of discussion, some makes sense, while a lot doesn't :). Let me start with the main points. bq. HRegion.processRowsWithLocks() implementation, doesn't call coprocessor hooks but instead calls RowProcessor hooks at appropriate point in execution. Many of these hooks/ methods have same names and are called at similar points during the course of execution but they are not related! That's because RowProcessor is not necessarily doing mutations. It's can be doing anything- reading, writing, aggregating, etc. For eg. if i am storing analytics data, I may want to write a RowProcessor which can aggregates large amount of data on server itself and just returns the result. There's no need of coprocessor hooks for this use case. (yeah yeahbetter use something else for analytics, but you get the point). It's not necessarily for mutations, it's much more generic and powerful. bq. HRegion.batchMutate() methods call coprocessor hooks but not row RowProcessor hooks. I think hook is bad word to use here. Yeah both CP and RP have overridable function, but that's where similarity ends. CP hooks are events which are invoked when specific code path is travelled. This is a promise we make to third party. That's why on every put, get, delete, we invoke pre\*/post\* functions. RowProcessor functions are not events. RowProcessor class is like a task - a collection of functions - which is given to HRegion. And at different stages, HRegion invokes appropriate function of the processor. The act of running a RowProcessor has no *direct* relation to Coprocessors (in specific implementations, work done by RP might be related to CP). So batchMutate(), which has nothing to do with RowProcessor and should not be invoking RowProcessor hooks anyways. bq. The major inconsistency here is, one code path uses coprocessors while other uses RowProcessor. There are other minor inconsistencies along those two code paths. It's confusing as hell, sure, but my understanding is that there is no inconsistency here. One path is mutations, and is supposed to invoke coprocessors. Other path is very high level, generic, row processing mechanism. And is only supposed to invoke right RowProcessors steps at right time. Since we use the second more generic path for mutateRows(), with the help of MultiRowMutationProcessor, it's only correct to invoke appropriate CP hooks from inside it, otherwise we'll be violating our CP promises. bq. Comparing these list of steps for 2 methods, we can see the correlation for most hooks except for RowProcessor.process() I think it's only expected. batchMutate() already knows what the mutations are. It's coming into it as a param. Easy peesy. But poor processRowsWithLocks() doesn't know what it was called for, so it still has to figure it out, and it does so by asking RP for the mutations. Let's be sympathetic. On a serious note, that's by design. bq. I am proposing that Coprocessors can be used for customized processing instead of RowProcessor. Currently this can be done either with RowProcessors by calling Region.processRowsWithLocks() or with coprocessors by calling Region.batchMutate(). The intended difference between these 2 APIs is that Region.batchMutate() will only perform PUT and DELETE operations and Region.processRowsWithLocks() can perform any of GET, PUT, DELETE, CheckAndMutate etc operations. So if RowProcessor is more generic, shouldn't we move to it? Why move to an option which is the limited one. Note that in batchMutate(), mutations are not related. The batch is not a transaction. Some can fail, some can pass. Whereas in processRowsWithLocks(), it's transactional. So even if we merge two code paths, we need to keep two kinds of locking . The way i see RowProcessor & processRows() combo is - it will allow us to separate out row operations and pack them neatly in classes (outside of HRegion, 8000lines!!), and that too in a way such that it is easy to inject back. I think the better design here would be, improve the RowProcessor to provide native support for mutations - locks, invoking cp hooks etc. That way we can use it for our internal purpose. Advantages are (explicitly listing them again): 1) lot of code sharing : Code around locking, wal edits, pre/postCP hooks can be shared. Move batchMutation() to BatchMutationProcessor, and rename MultiRowMutationProcessor to denote that unlike BatchMutationProcessor, it's transactional. 2) We can split out all mutations related logic from 8000 lines of HRegion class. 3) It'll be a better design to expose for use in CPs. Taking a step back, yes, it's a mess. Unification of two paths would be great! >
[jira] [Updated] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[ https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-12260: -- Attachment: HBASE-12260.master.012.patch > MasterServices needs a short-back-and-sides; pare-back exposure of internals > and IA.Private classes > --- > > Key: HBASE-12260 > URL: https://issues.apache.org/jira/browse/HBASE-12260 > Project: HBase > Issue Type: Sub-task > Components: master >Reporter: ryan rawson >Assignee: stack >Priority: Critical > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-12260.master.001.patch, > HBASE-12260.master.002.patch, HBASE-12260.master.003.patch, > HBASE-12260.master.004.patch, HBASE-12260.master.005.patch, > HBASE-12260.master.006.patch, HBASE-12260.master.007.patch, > HBASE-12260.master.008.patch, HBASE-12260.master.009.patch, > HBASE-12260.master.010.patch, HBASE-12260.master.011.patch, > HBASE-12260.master.011.patch, HBASE-12260.master.012.patch > > > A major issue with MasterServices is the MasterCoprocessorEnvironment exposes > this class even though MasterServices is tagged with > @InterfaceAudience.Private > This means that the entire internals of the HMaster is essentially part of > the coprocessor API. Many of the classes returned by the MasterServices API > are highly internal, extremely powerful, and subject to constant change. > Perhaps a new API to replace MasterServices that is use-case focused, and > justified based on real world co-processors would suit things better. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18949) Remove the CompactionRequest parameter in preCompactSelection
[
https://issues.apache.org/jira/browse/HBASE-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198038#comment-16198038
]
Peter Somogyi commented on HBASE-18949:
---
Thanks for reviewing and committing the fix!
> 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-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=16198032#comment-16198032
]
Mike Drob commented on HBASE-18867:
---
cc: [~mantonov] [~busbey] [~ndimiduk]
> 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/2.2/plexus-archiver-2.2.jar
> [ERROR] urls[26] =
>
[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=16198029#comment-16198029 ] Duo Zhang commented on HBASE-18957: --- I skimmed all the related issues and didn't find out what is the final behavior we all agree with. Can you guys please add a clear description of what the expected behavior is in the description? Thanks. > 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-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:all-tabpanel
]
Mike Drob updated HBASE-18867:
--
Fix Version/s: 1.1.13
1.2.7
1.3.2
> 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/2.2/plexus-archiver-2.2.jar
> [ERROR] urls[26] =
>
[jira] [Updated] (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:all-tabpanel
]
Mike Drob updated HBASE-18867:
--
Attachment: HBASE-18867.branch-1.3.patch
Attaching a branch-1.3 patch as well, since that one _also_ doesn't cherry-pick
cleanly from branch-1/branch-2. 1.3 patch is good all the way back to 1.1
though.
Will wait for a review on both flavors of branch-1 patches before pushing
anything else.
> 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.5.0
>
> 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] =
>
[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=16198023#comment-16198023
]
Hadoop QA commented on HBASE-16338:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 12m
29s{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} shelldocs {color} | {color:blue} 0m
5s{color} | {color:blue} Shelldocs was not available. {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
17s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
39s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
4s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
7s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
1s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m
0s{color} | {color:blue} Skipped patched modules with no Java source:
hbase-resource-bundle hbase-shaded hbase-shaded/hbase-shaded-mapreduce .
{color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
23s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
40s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
17s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
23s{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
16s{color} | {color:red} hbase-mapreduce in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
15s{color} | {color:red} hbase-it in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
12s{color} | {color:red} hbase-shaded in the patch failed. {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m
10s{color} | {color:red} hbase-shaded-mapreduce in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 6m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 6m
6s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} rubocop {color} | {color:green} 0m
3s{color} | {color:green} There were no new rubocop issues. {color} |
| {color:green}+1{color} | {color:green} ruby-lint {color} | {color:green} 0m
1s{color} | {color:green} There were no new ruby-lint issues. {color} |
| {color:green}+1{color} | {color:green} shellcheck {color} | {color:green} 0m
6s{color} | {color:green} There were no new shellcheck issues. {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m
10s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
32s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
40m 28s{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
[jira] [Updated] (HBASE-18949) Remove the CompactionRequest parameter in preCompactSelection
[
https://issues.apache.org/jira/browse/HBASE-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-18949:
--
Release Note: Remove the CompactionRequest parameter in preCompactSelection
as we do not have a CompactionRequest at that time.
> 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-18949) Remove the CompactionRequest parameter in preCompactSelection
[
https://issues.apache.org/jira/browse/HBASE-18949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-18949:
--
Resolution: Fixed
Fix Version/s: 3.0.0
Status: Resolved (was: Patch Available)
Pushed to master and branch-2.
Thanks [~psomogyi].
> 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-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=16198016#comment-16198016
]
Andrew Purtell commented on HBASE-18867:
[~mdrob] Yeah we want to compile with all the GA Javas >= 7.
> 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.5.0
>
> Attachments: HBASE-18867.0.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/2.2/plexus-archiver-2.2.jar
> [ERROR] urls[26] =
>
[jira] [Comment Edited] (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=16198009#comment-16198009
]
Mike Drob edited comment on HBASE-18867 at 10/10/17 1:41 AM:
-
Pushed to branch-2 and master, attaching a branch-1 patch since that didn't
apply cleanly.
[~apurtell] - do you even want this on branch-1.4? not sure if compiling with
java9 is a non-goal for the release.
was (Author: mdrob):
Pushed to branch-2 and master, attaching a branch-1 patch since that didn't
apply cleanly.
> 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.5.0
>
> Attachments: HBASE-18867.0.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] =
>
[jira] [Updated] (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:all-tabpanel
]
Mike Drob updated HBASE-18867:
--
Attachment: HBASE-18867.branch-1.patch
Pushed to branch-2 and master, attaching a branch-1 patch since that didn't
apply cleanly.
> 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.5.0
>
> Attachments: HBASE-18867.0.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/2.2/plexus-archiver-2.2.jar
> [ERROR] urls[26] =
>
[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=16198008#comment-16198008 ] Jingcheng Du commented on HBASE-18693: -- Sure, [~huaxiang]. I am looking at it. It may take a few days. Thanks. > 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-18955) HBase client queries stale hbase:meta location with half-dead RegionServer
[
https://issues.apache.org/jira/browse/HBASE-18955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16198005#comment-16198005
]
Enis Soztutar commented on HBASE-18955:
---
The problem is that if the server is "half dead" the TCP sockets are still
open, so the RPCs going to it will succeed, and only will fail with CTE after
60 seconds. Invalidating the meta's location from SSH seems better, since
MetaSSH already knows that the meta server is dead.
> HBase client queries stale hbase:meta location with half-dead RegionServer
> --
>
> Key: HBASE-18955
> URL: https://issues.apache.org/jira/browse/HBASE-18955
> Project: HBase
> Issue Type: Bug
> Components: Client
>Affects Versions: 1.1.12
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Critical
> Fix For: 1.1.13
>
> Attachments: HBASE-18995.001.branch-1.1.patch
>
>
> Have been investigating a case with [~tedyu] where, when a RegionServer
> becomes "hung" (for no specific reason -- not the point), the client becomes
> stuck trying to talk to this RegionServer, never exiting. This was eventually
> tracked down to HBASE-15645. However, in testing the fix, I found that there
> is an additional problem which only affects branch-1.1.
> When the RegionServer in the "half-dead" state is also hosting meta, the
> hbase client (both the one trying to read data, but also the client in the
> Master trying to read meta in SSH) get stuck repeatedly trying to read meta
> from the old location after meta has been reassigned.
> The general test outline goes like this:
> * Start at least 2 regionservers
> * Load some data into a table ({{hbase pe}} is great)
> * Find a region that is hosted by the same RS that is hosting meta
> * {{kill -SIGSTOP}} that RS hosting the user region and meta
> * Issue a {{get}} in the hbase-shell trying to read from that user region
> The expectation is that the ZK lock will expire for the STOP'ed RS, meta will
> be reassigned, then the user regions will be reassigned, then the client will
> get the result of the get without seeing an error (as long as this happens
> within the hbase.client.operation.timeout value, of course).
> We see this happening on HBase 1.2.4 and 1.3.2-SNAPSHOT, but, on
> 1.1.13-SNAPSHOT, the Master gets up to re-assigning meta, but then gets stuck
> trying to read meta from the STOP'ed RS instead of where it re-assigned it.
> Because of this, the regions stay in transition until the master is restarted
> or the STOP'ed RS is CONT'ed. My best guess is that when the RS sees the
> {{SIGCONT}}, it immediately begins stopping which is enough to kick the
> client into refreshing the region location cache.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [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=16197957#comment-16197957 ] Hudson commented on HBASE-18957: FAILURE: Integrated in Jenkins build HBase-1.5 #89 (See [https://builds.apache.org/job/HBase-1.5/89/]) HBASE-18957 add test that confirms 2 FamilyFilters in a FilterList using (busbey: rev 8d77c1e95480d5658bd4ebccb5cc56bdd387c886) * (add) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterListOnMini.java > 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] [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=16197958#comment-16197958 ] Hudson commented on HBASE-15410: FAILURE: Integrated in Jenkins build HBase-1.5 #89 (See [https://builds.apache.org/job/HBase-1.5/89/]) Revert "HBASE-15410 Utilize the max seek value when all Filters in (busbey: rev c7dc0da849e543cc5205f54eb69c5d75bd442f73) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java * (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java > 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 > > 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=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-17678) FilterList with MUST_PASS_ONE may lead to redundant cells returned
[
https://issues.apache.org/jira/browse/HBASE-17678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197959#comment-16197959
]
Hudson commented on HBASE-17678:
FAILURE: Integrated in Jenkins build HBase-1.5 #89 (See
[https://builds.apache.org/job/HBase-1.5/89/])
Revert "HBASE-17678 FilterList with MUST_PASS_ONE may lead to redundant
(busbey: rev aa50971947b2eee9b5b9b4700e0b8a0fa93b377f)
* (edit)
hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilterList.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/KeyValueUtil.java
* (edit)
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/FilterList.java
> FilterList with MUST_PASS_ONE may lead to redundant cells returned
> --
>
> Key: HBASE-17678
> URL: https://issues.apache.org/jira/browse/HBASE-17678
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 2.0.0, 1.3.0, 1.2.1
> Environment: RedHat 7.x
>Reporter: Jason Tokayer
>Assignee: Zheng Hu
> Attachments: HBASE-17678.addendum.patch, HBASE-17678.addendum.patch,
> HBASE-17678.branch-1.1.v1.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.1.v2.patch, HBASE-17678.branch-1.1.v2.patch,
> HBASE-17678.branch-1.v1.patch, HBASE-17678.branch-1.v1.patch,
> HBASE-17678.branch-1.v2.patch, HBASE-17678.branch-1.v2.patch,
> HBASE-17678.v1.patch, HBASE-17678.v1.rough.patch, HBASE-17678.v2.patch,
> HBASE-17678.v3.patch, HBASE-17678.v4.patch, HBASE-17678.v4.patch,
> HBASE-17678.v5.patch, HBASE-17678.v6.patch, HBASE-17678.v7.patch,
> HBASE-17678.v7.patch, TestColumnPaginationFilterDemo.java
>
>
> When combining ColumnPaginationFilter with a single-element filterList,
> MUST_PASS_ONE and MUST_PASS_ALL give different results when there are
> multiple cells with the same timestamp. This is unexpected since there is
> only a single filter in the list, and I would believe that MUST_PASS_ALL and
> MUST_PASS_ONE should only affect the behavior of the joined filter and not
> the behavior of any one of the individual filters. If this is not a bug then
> it would be nice if the documentation is updated to explain this nuanced
> behavior.
> I know that there was a decision made in an earlier Hbase version to keep
> multiple cells with the same timestamp. This is generally fine but presents
> an issue when using the aforementioned filter combination.
> Steps to reproduce:
> In the shell create a table and insert some data:
> {code:none}
> create 'ns:tbl',{NAME => 'family',VERSIONS => 100}
> put 'ns:tbl','row','family:name','John',1
> put 'ns:tbl','row','family:name','Jane',1
> put 'ns:tbl','row','family:name','Gil',1
> put 'ns:tbl','row','family:name','Jane',1
> {code}
> Then, use a Scala client as:
> {code:none}
> import org.apache.hadoop.hbase.filter._
> import org.apache.hadoop.hbase.util.Bytes
> import org.apache.hadoop.hbase.client._
> import org.apache.hadoop.hbase.{CellUtil, HBaseConfiguration, TableName}
> import scala.collection.mutable._
> val config = HBaseConfiguration.create()
> config.set("hbase.zookeeper.quorum", "localhost")
> config.set("hbase.zookeeper.property.clientPort", "2181")
> val connection = ConnectionFactory.createConnection(config)
> val logicalOp = FilterList.Operator.MUST_PASS_ONE
> val limit = 1
> var resultsList = ListBuffer[String]()
> for (offset <- 0 to 20 by limit) {
> val table = connection.getTable(TableName.valueOf("ns:tbl"))
> val paginationFilter = new ColumnPaginationFilter(limit,offset)
> val filterList: FilterList = new FilterList(logicalOp,paginationFilter)
> println("@ filterList = "+filterList)
> val results = table.get(new
> Get(Bytes.toBytes("row")).setFilter(filterList))
> val cells = results.rawCells()
> if (cells != null) {
> for (cell <- cells) {
> val value = new String(CellUtil.cloneValue(cell))
> val qualifier = new String(CellUtil.cloneQualifier(cell))
> val family = new String(CellUtil.cloneFamily(cell))
> val result = "OFFSET = "+offset+":"+family + "," + qualifier
> + "," + value + "," + cell.getTimestamp()
> resultsList.append(result)
> }
> }
> }
> resultsList.foreach(println)
> {code}
> Here are the results for different limit and logicalOp settings:
> {code:none}
> Limit = 1 & logicalOp = MUST_PASS_ALL:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> Limit = 1 & logicalOp = MUST_PASS_ONE:
> scala> resultsList.foreach(println)
> OFFSET = 0:family,name,Jane,1
> OFFSET = 1:family,name,Gil,1
> OFFSET = 2:family,name,Jane,1
> OFFSET = 3:family,name,John,1
> Limit = 2 &
[jira] [Updated] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Purtell updated HBASE-18923: --- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 1.5.0 1.4.0 Status: Resolved (was: Patch Available) Pushed to branch-1.4 and branch-1. Thanks a lot for the patch [~pankaj_kumar]! > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-18923-branch-1-V2.patch, HBASE-18923-branch-1.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18923) TestTableResource flaky on branch-1
[ https://issues.apache.org/jira/browse/HBASE-18923?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197895#comment-16197895 ] Andrew Purtell commented on HBASE-18923: +1 Let me do a couple of checks, then commit > TestTableResource flaky on branch-1 > --- > > Key: HBASE-18923 > URL: https://issues.apache.org/jira/browse/HBASE-18923 > Project: HBase > Issue Type: Bug >Affects Versions: 1.4.0, 1.5.0 >Reporter: Andrew Purtell >Assignee: Pankaj Kumar > Attachments: HBASE-18923-branch-1-V2.patch, HBASE-18923-branch-1.patch > > > Occasional NPE > Flaked tests: > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoPB(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoPB:271->checkTableInfo:184 NullPointer > Run 2: PASS > org.apache.hadoop.hbase.rest.TestTableResource.testTableInfoXML(org.apache.hadoop.hbase.rest.TestTableResource) > Run 1: TestTableResource.testTableInfoXML:254->checkTableInfo:184 > NullPointer > Run 2: PASS > Tests run: 213, Failures: 0, Errors: 0, Skipped: 0, Flakes: 2 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[
https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197882#comment-16197882
]
Hadoop QA commented on HBASE-18960:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
10s{color} | {color:blue} Docker mode activated. {color} |
| {color: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
48s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{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
3s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
37s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
59s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
57s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
33m 56s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
7s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
43s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
17s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 90m
42s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
29s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}148m 48s{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-18960 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891126/hbase-18960.master.003.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 840e58101b3c 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] [Updated] (HBASE-18975) B hadoop3 incompatibility
[
https://issues.apache.org/jira/browse/HBASE-18975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-18975:
---
Attachment: testIncrementalBackup-output.tar.gz
> B 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, 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] [Commented] (HBASE-18975) B hadoop3 incompatibility
[
https://issues.apache.org/jira/browse/HBASE-18975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197856#comment-16197856
]
Vladimir Rodionov commented on HBASE-18975:
---
[~te...@apache.org], can you attach the full log?
> B 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
>
>
> 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] [Commented] (HBASE-12260) MasterServices needs a short-back-and-sides; pare-back exposure of internals and IA.Private classes
[
https://issues.apache.org/jira/browse/HBASE-12260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197853#comment-16197853
]
Hadoop QA commented on HBASE-12260:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
13s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m
0s{color} | {color:green} The patch appears to include 42 new or modified test
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
44s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
57s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 6m
43s{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
15s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
15s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m
18s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
40s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m
39s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 2m
0s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m
7s{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
41s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
45m 32s{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
26s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
56s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 24m 8s{color}
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m
37s{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 9m
8s{color} | {color:green} hbase-backup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
37s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}116m 10s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestClockSkewDetection |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:5d60123 |
| JIRA Issue | HBASE-12260 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891129/HBASE-12260.master.011.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
[jira] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Attachment: (was: HBASE-15631-branch-1.patch) > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, > HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Attachment: HBASE-15631-branch-1.patch > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, > HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18974) Document "Becoming a Committer"
[ https://issues.apache.org/jira/browse/HBASE-18974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197827#comment-16197827 ] Chia-Ping Tsai commented on HBASE-18974: quoting [~misty]'s list # Contribute to the docs (yay!) # Help fix and improve testing # Participate in release candidate votes, even if non-binding # Review other people's work # Help newbies # Answer questions # Update the website # File issues # Mentor new contributors of all sorts # Give talks about HBase # Write blogs about HBase # Participate in design discussions # Provide UX feedback # Write demo applications # Help us attract and retain a diverse community # Interact with other projects in ways that benefit HBase and those other projects > Document "Becoming a Committer" > --- > > Key: HBASE-18974 > URL: https://issues.apache.org/jira/browse/HBASE-18974 > Project: HBase > Issue Type: Bug > Components: community, documentation >Reporter: Mike Drob > > Based on the mailing list discussion at > https://lists.apache.org/thread.html/81c633cbe1f6f78421cbdad5b9549643c67803a723a9d86a513264c0@%3Cdev.hbase.apache.org%3E > it sounds like we should record some of the thoughts for future contributors > to refer to. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[
https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16197824#comment-16197824
]
Hadoop QA commented on HBASE-18960:
---
| (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} docker {color} | {color:red} 0m
13s{color} | {color:red} Docker failed to build yetus/hbase:5d60123. {color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Issue | HBASE-18960 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12891154/hbase-18960.master.005.patch
|
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9011/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
This message was automatically generated.
> A few bug fixes and minor improvements around batchMutate()
> ---
>
> Key: HBASE-18960
> URL: https://issues.apache.org/jira/browse/HBASE-18960
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
>Affects Versions: 2.0.0-alpha-3
>Reporter: Umesh Agashe
>Assignee: Umesh Agashe
> Fix For: 2.0.0-alpha-4
>
> Attachments: hbase-18960.master.001.patch,
> hbase-18960.master.002.patch, hbase-18960.master.003.patch,
> hbase-18960.master.004.patch, hbase-18960.master.005.patch
>
>
> Batch validation and preparation can be done before we start iterating over
> batch operations for writes. observedExceptions, familyCellMaps and
> durability can be stored in BatchOperation as they are batch wide. For all
> operations, done by preBatchMutate() CP hook, operation status needs to be
> SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate().
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Issue Comment Deleted] (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:all-tabpanel
]
Andrew Purtell updated HBASE-15631:
---
Comment: was deleted
(was: | (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
30s{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 18 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} 1m
51s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 4m
46s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 5m
12s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 27m
46s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 3m
4s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
30s{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
16s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 4m
4s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 5m
30s{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
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
20s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
20s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
20s{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
14s{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
15s{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
31s{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
12s{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
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} 1m
22s{color} | {color:green} root in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
14s{color} | {color:green} hbase-it in the patch passed with JDK v1.8.0_144.
{color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 3m
44s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 3m
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
20s{color} | {color:green} hbase-protocol in the patch passed
[jira] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Fix Version/s: 1.5.0 1.4.0 Status: Patch Available (was: Open) > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, > HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Issue Comment Deleted] (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:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Comment: was deleted (was: Dropping a new version of the patch addressing [~toffer]'s reviewboard feedback. The common theme of his feedback was the branch-1 backport diverged from >= branch-2 in some interfaces, due to the branch-1 work being based on an older rev of the feature. I have fixed this by checking out branch-2's hbase-rsgroup module at a71f62de and making the minimum number of fixups to get it compiling in place in branch-1. This required adding Address to hbase-common and addition of a couple of methods for dealing with Addresses to ServerName in hbase-client. Not tested yet. WIP ) > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Fix For: 1.4.0, 1.5.0 > > Attachments: HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, > HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (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:all-tabpanel ] Andrew Purtell updated HBASE-15631: --- Attachment: HBASE-15631-branch-1.patch Address review feedback - Use Address instead of HostAndPort - Move rsgroup specific protobuf serde from ProtobufUtil to RSGroupProtobufUtil - Replace NAMESPACEDESC_PROP_GROUP with NAMESPACE_DESC_PROP_GROUP in RSGroupInfo - Sync RSGroupAdmin interface with that defined in branch-2 and master - Sync RSGroupAdminClient interface with that defined in branch-2 and master - Sync RSGroupInfoManager interface with that defined in branch-2 and master Tests are passing > Backport Regionserver Groups (HBASE-6721) to branch-1 > -- > > Key: HBASE-15631 > URL: https://issues.apache.org/jira/browse/HBASE-15631 > Project: HBase > Issue Type: New Feature >Affects Versions: 1.4.0 >Reporter: Francis Liu >Assignee: Francis Liu > Attachments: HBASE-15631-branch-1.patch, HBASE-15631.branch-1.patch, > HBASE-15631.patch > > > Based on dev list discussion backporting region server group should not be an > issue as it does not: 1. destabilize the code. 2. cause backward > incompatibility. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18960) A few bug fixes and minor improvements around batchMutate()
[ https://issues.apache.org/jira/browse/HBASE-18960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Umesh Agashe updated HBASE-18960: - Attachment: hbase-18960.master.005.patch Fixed build error in previous patch 004 and a change per review comment. > A few bug fixes and minor improvements around batchMutate() > --- > > Key: HBASE-18960 > URL: https://issues.apache.org/jira/browse/HBASE-18960 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-alpha-4 > > Attachments: hbase-18960.master.001.patch, > hbase-18960.master.002.patch, hbase-18960.master.003.patch, > hbase-18960.master.004.patch, hbase-18960.master.005.patch > > > Batch validation and preparation can be done before we start iterating over > batch operations for writes. observedExceptions, familyCellMaps and > durability can be stored in BatchOperation as they are batch wide. For all > operations, done by preBatchMutate() CP hook, operation status needs to be > SUCCESS. Modify and use doWALAppend() from doMiniBatchMutate(). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
