[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Status: Patch Available (was: Open) > Make a Public interface for CellComparator > -- > > Key: HBASE-18945 > URL: https://issues.apache.org/jira/browse/HBASE-18945 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18495.patch, HBASE-18945_2.patch, > HBASE-18945_3.patch, HBASE-18945_4.patch, HBASE-18945_5.patch, > HBASE-18945_6.patch > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Attachment: HBASE-18945_6.patch Updated patch. Fixed the java doc comments. All tests passes now. Ping for comments/+1. > 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-alpha-4 > > Attachments: HBASE-18495.patch, HBASE-18945_2.patch, > HBASE-18945_3.patch, HBASE-18945_4.patch, HBASE-18945_5.patch, > HBASE-18945_6.patch > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-18945) Make a Public interface for CellComparator
[ https://issues.apache.org/jira/browse/HBASE-18945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ramkrishna.s.vasudevan updated HBASE-18945: --- Status: Open (was: Patch Available) > Make a Public interface for CellComparator > -- > > Key: HBASE-18945 > URL: https://issues.apache.org/jira/browse/HBASE-18945 > Project: HBase > Issue Type: Sub-task >Reporter: ramkrishna.s.vasudevan >Assignee: ramkrishna.s.vasudevan > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18495.patch, HBASE-18945_2.patch, > HBASE-18945_3.patch, HBASE-18945_4.patch, HBASE-18945_5.patch > > > Based on discussions over in HBASE-18826 and HBASE-18183 it is better we > expose CellComparator as a public interface so that it could be used in > Region/Store interfaces to be exposed to CPs. > Currently the Comparator is exposed in Region, STore and StoreFile. There is > another discussion whether to expose it at all layers or only at Region. > However since we are exposing this to CPs CellComparator being @Private is > not the ideal way to do it. We have to change it to LimitedPrivate. But > CellComparator has lot of additional methods which are internal (like where a > Cell is compared with an incoming byte[] used in index comparsions etc). > One way to expose is that as being done now in HBASE-18826 - by exposing the > return type as Comparator. But this is not powerful. It only allows to > compare cells. So we try to expose an IA.LimitedPrivate interface that is > more powerful and allows comparing individual cell components also. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19008) Add missing equals or hashCode method(s) to stock Filter implementations
[
https://issues.apache.org/jira/browse/HBASE-19008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205442#comment-16205442
]
ramkrishna.s.vasudevan commented on HBASE-19008:
We need equals and hashcode for Filters? What is the background? Some thing
like retrieving from a map or a set?
> Add missing equals or hashCode method(s) to stock Filter implementations
>
>
> Key: HBASE-19008
> URL: https://issues.apache.org/jira/browse/HBASE-19008
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
>Assignee: Jan Hentschel
>
> In HBASE-15410, [~mdrob] reminded me that Filter implementations may not
> write {{equals}} or {{hashCode}} method(s).
> This issue is to add missing {{equals}} or {{hashCode}} method(s) to stock
> Filter implementations such as KeyOnlyFilter.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205436#comment-16205436 ] ramkrishna.s.vasudevan commented on HBASE-19007: Proposal makes sense. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (HBASE-19014) surefire fails; When writing xml report stdout/stderr ... No such file or directory
[
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai reassigned HBASE-19014:
--
Assignee: Chia-Ping Tsai
> surefire fails; When writing xml report stdout/stderr ... No such file or
> directory
> ---
>
> Key: HBASE-19014
> URL: https://issues.apache.org/jira/browse/HBASE-19014
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
>
> {code}
> 17:22:33 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (secondPartTestsExecution) on project hbase-server: ExecutionException:
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.maven.surefire.report.ReporterException: When writing xml report
> stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
> directory) -> [Help 1]
> {code}
> It happens frequently on my jenkins...I update the surefire to 2.20.1, and
> then the failure doesn't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19014) surefire fails; When writing xml report stdout/stderr ... No such file or directory
[
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205435#comment-16205435
]
Chia-Ping Tsai commented on HBASE-19014:
What I'm going to do is to update the version of surefire to 2.20.x, but
# the 2.20 broke package-wildcard for test specification (see HBASE-18364, and
ping [~elserj])
# not sure whether this issue occurs on our QA because I don't find the related
error message on our jenkins.
> surefire fails; When writing xml report stdout/stderr ... No such file or
> directory
> ---
>
> Key: HBASE-19014
> URL: https://issues.apache.org/jira/browse/HBASE-19014
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
>
> {code}
> 17:22:33 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (secondPartTestsExecution) on project hbase-server: ExecutionException:
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.maven.surefire.report.ReporterException: When writing xml report
> stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
> directory) -> [Help 1]
> {code}
> It happens frequently on my jenkins...I update the surefire to 2.20.1, and
> then the failure doesn't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18967) Backport HBASE-17181 to branch-1.3
[ https://issues.apache.org/jira/browse/HBASE-18967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205431#comment-16205431 ] Chia-Ping Tsai commented on HBASE-18967: I ran the TestThriftServerCmdLine with ur patch 10 times. Never fails...It seems our QA encounter some trouble. Could you submit a patch having a trivial change in thrift module to trigger the QA again? > Backport HBASE-17181 to branch-1.3 > -- > > Key: HBASE-18967 > URL: https://issues.apache.org/jira/browse/HBASE-18967 > Project: HBase > Issue Type: Sub-task >Reporter: Chia-Ping Tsai >Assignee: Peter Somogyi > Fix For: 1.3.2 > > Attachments: HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch, HBASE-18967.branch-1.3.001.patch, > HBASE-18967.branch-1.3.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205424#comment-16205424
]
Dave Latham commented on HBASE-14247:
-
No, thank you.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff, HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247.master.003.patch,
> HBASE-14247.master.004.patch, HBASE-14247.master.005.patch
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18996) Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to branch-1
[
https://issues.apache.org/jira/browse/HBASE-18996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205407#comment-16205407
]
Hadoop QA commented on HBASE-18996:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 13m
59s{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 1 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
5s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
19s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
9s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
17s{color} | {color:green} branch-1 passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
23s{color} | {color:green} branch-1 passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
42s{color} | {color:green} branch-1 passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
23s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
23s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
25s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
15s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 2m
35s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 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} findbugs {color} | {color:green} 1m
27s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
26s{color} | {color:green} the patch passed with JDK v1.8.0_144 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
39s{color} | {color:green} the patch passed with JDK v1.7.0_151 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 18m 38s{color}
| {color:red} hbase-thrift in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 72m 17s{color} |
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests |
org.apache.hadoop.hbase.thrift.TestThriftServerCmdLine |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:6f1cc2c |
| JIRA Issue | HBASE-18996 |
| JIRA Patch URL |
[jira] [Updated] (HBASE-18879) HBase FilterList cause KeyOnlyFilter not work
[
https://issues.apache.org/jira/browse/HBASE-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duo Zhang updated HBASE-18879:
--
Resolution: Fixed
Hadoop Flags: Reviewed
Status: Resolved (was: Patch Available)
Pushed to HBASE-18410. Thanks all.
> HBase FilterList cause KeyOnlyFilter not work
> -
>
> Key: HBASE-18879
> URL: https://issues.apache.org/jira/browse/HBASE-18879
> Project: HBase
> Issue Type: Sub-task
> Components: Filters
>Affects Versions: 1.2.4
> Environment: OS： Red Hat 4.4.7-11
> Hadoop: 2.6.4
> Hbase: 1.2.4
>Reporter: ZHA_Moonlight
>Assignee: Zheng Hu
> Attachments: HBASE-18879-HBASE-18410.v1.patch,
> HBASE-18879-HBASE-18410.v2.patch
>
>
> when use FilterList and KeyOnlyFilter together, if we put KeyOnlyFilter
> before FilterList, the KeyOnlyFilter may not work, means it will also grab
> the cell values:
> {code:java}
> List filters = new ArrayList();
> Filter filter1 = new SingleColumnValueFilter(Bytes.toBytes("cf"),
> Bytes.toBytes("column1"),
> CompareOp.EQUAL, Bytes.toBytes("value1"));
> Filter filter2 = new SingleColumnValueFilter(Bytes.toBytes("cf"),
> Bytes.toBytes("column1"),
> CompareOp.EQUAL, Bytes.toBytes("value2"));
> filters.add(filter1);
> filters.add(filter2);
> FilterList filterListAll = new FilterList(Operator.MUST_PASS_ALL,
> new KeyOnlyFilter(),
> new FilterList(Operator.MUST_PASS_ONE, filters));
> {code}
> use the above code as filter to scan a table, it will return the cells with
> value instead of only return the key, if we put KeyOnlyFilter after
> FilterList as following, it works well.
>
> {code:java}
> FilterList filterListAll = new FilterList(Operator.MUST_PASS_ALL,
> new FilterList(Operator.MUST_PASS_ONE, filters),
> new KeyOnlyFilter());
> {code}
> the cause should due to the following code at hbase-client FilterList.java
> {code:java}
> @Override
>
> @edu.umd.cs.findbugs.annotations.SuppressWarnings(value="SF_SWITCH_FALLTHROUGH",
> justification="Intentional")
> public ReturnCode filterKeyValue(Cell v) throws IOException {
> this.referenceKV = v;
> // Accumulates successive transformation of every filter that includes
> the Cell:
> Cell transformed = v;
> ReturnCode rc = operator == Operator.MUST_PASS_ONE?
> ReturnCode.SKIP: ReturnCode.INCLUDE;
> int listize = filters.size();
> for (int i = 0; i < listize; i++) {
> Filter filter = filters.get(i);
> if (operator == Operator.MUST_PASS_ALL) {
> if (filter.filterAllRemaining()) {
> return ReturnCode.NEXT_ROW;
> }
> LINE1 ReturnCode code = filter.filterKeyValue(v);{color}
> switch (code) {
> // Override INCLUDE and continue to evaluate.
> case INCLUDE_AND_NEXT_COL:
> rc = ReturnCode.INCLUDE_AND_NEXT_COL; // FindBugs
> SF_SWITCH_FALLTHROUGH
> case INCLUDE:
> LINE2 transformed = filter.transformCell(transformed);{color}
>
> continue;
> case SEEK_NEXT_USING_HINT:
> seekHintFilter = filter;
> return code;
> default:
> return code;
> }
> }
> {code}
> notice the “LINE1”,"LINE2" , first line is a recursive invocation, it will
> assign a Cell results to the FilterList.transformedKV(we call it A), the
> results is from the FilterList with 2 SingleColumnValueFilter, so A with
> contains the cell value, while the second line with return A to the var
> transformed.
> back to the following loop, we can see the FilterList return results is var
> "transformed " which will override in each loop, so the value is determined
> by the last filter, so the order of KeyOnlyFilter will impact the results.
> {code:java}
> Cell transformed = v;
> ReturnCode rc = operator == Operator.MUST_PASS_ONE?
> ReturnCode.SKIP: ReturnCode.INCLUDE;
> int listize = filters.size();
> for (int i = 0; i < listize; i++) {
> Filter filter = filters.get(i);
> if (operator == Operator.MUST_PASS_ALL) {
> if (filter.filterAllRemaining()) {
> return ReturnCode.NEXT_ROW;
> }
> ReturnCode code = filter.filterKeyValue(v);
> switch (code) {
> // Override INCLUDE and continue to evaluate.
> case INCLUDE_AND_NEXT_COL:
> rc = ReturnCode.INCLUDE_AND_NEXT_COL; // FindBugs
> SF_SWITCH_FALLTHROUGH
> case INCLUDE:
> transformed = filter.transformCell(transformed);
> continue;
> case SEEK_NEXT_USING_HINT:
> seekHintFilter = filter;
> return code;
> default:
> return code;
> }
>
> {code}
--
[jira] [Commented] (HBASE-14247) Separate the old WALs into different regionserver directories
[
https://issues.apache.org/jira/browse/HBASE-14247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205383#comment-16205383
]
Guanghao Zhang commented on HBASE-14247:
Thanks [~Apache9] for reviewing.
[~davelatham] Do you have more concerns? If not, I will commit it tomorrow.
Thanks.
> Separate the old WALs into different regionserver directories
> -
>
> Key: HBASE-14247
> URL: https://issues.apache.org/jira/browse/HBASE-14247
> Project: HBase
> Issue Type: Improvement
> Components: wal
>Reporter: Liu Shaohui
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-14247-v001.diff, HBASE-14247-v002.diff,
> HBASE-14247-v003.diff, HBASE-14247.master.001.patch,
> HBASE-14247.master.002.patch, HBASE-14247.master.003.patch,
> HBASE-14247.master.004.patch, HBASE-14247.master.005.patch
>
>
> Currently all old WALs of regionservers are achieved into the single
> directory of oldWALs. In big clusters, because of long TTL of WAL or disabled
> replications, the number of files under oldWALs may reach the
> max-directory-items limit of HDFS, which will make the hbase cluster crashed.
> {quote}
> Caused by:
> org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.protocol.FSLimitException$MaxDirectoryItemsExceededException):
> The directory item limit of /hbase/lgprc-xiaomi/.oldlogs is exceeded:
> limit=1048576 items=1048576
> {quote}
> A simple solution is to separate the old WALs into different directories
> according to the server name of the WAL.
> Suggestions are welcomed~ Thanks
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18996) Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to branch-1
[ https://issues.apache.org/jira/browse/HBASE-18996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Somogyi updated HBASE-18996: -- Attachment: HBASE-18996.branch-1.001.patch > Backport HBASE-17703 (TestThriftServerCmdLine is flaky in master branch) to > branch-1 > > > Key: HBASE-18996 > URL: https://issues.apache.org/jira/browse/HBASE-18996 > Project: HBase > Issue Type: Task > Components: Thrift >Affects Versions: 1.3.2, 1.4.1, 1.5.0, 1.2.7, 1.1.13 >Reporter: Peter Somogyi >Assignee: Peter Somogyi > Attachments: HBASE-18996.branch-1.001.patch, > HBASE-18996.branch-1.001.patch, HBASE-18996.branch-1.001.patch > > > During HBASE-18967 backport to branch-1.3 a test failure came up which was > fixed in HBASE-17703. > We need to backport it to branch-1. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205364#comment-16205364
]
Hudson commented on HBASE-18986:
FAILURE: Integrated in Jenkins build HBase-2.0 #693 (See
[https://builds.apache.org/job/HBase-2.0/693/])
HBASE-18986 Remove unnecessary null check after (jerryjch: rev
aeaf222e35e8a7d5c751477e7774417654062e54)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205355#comment-16205355
]
Hudson commented on HBASE-18986:
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3894 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/3894/])
HBASE-18986 Remove unnecessary null check after (jerryjch: rev
83af5f2c623cb3180ab21f17f5681d4328acdc76)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19015) hbase-shaded-check-invariants fails against hadoop3-beta1
Ted Yu created HBASE-19015:
--
Summary: hbase-shaded-check-invariants fails against hadoop3-beta1
Key: HBASE-19015
URL: https://issues.apache.org/jira/browse/HBASE-19015
Project: HBase
Issue Type: Bug
Reporter: Ted Yu
When using the following command trying to build tar ball against hadoop3 beta1:
{code}
mvn install -DskipTests -Phadoop-3.0 -Dhadoop-three.version=3.0.0-beta1
-Dhadoop-two.version=3.0.0-beta1 -Djetty.version=9.3.19.v20170502
assembly:single -Prelease
{code}
I got the following:
{code}
[ERROR] Found artifact with unexpected contents:
'/Users/tyu/.m2/repository/org/apache/hbase/hbase-shaded-client/3.0.0-SNAPSHOT/hbase-shaded-client-3.0.0-SNAPSHOT.jar'
Please check the following and either correct the build or update
the allowed list with reasoning.
com/
com/nimbusds/
com/nimbusds/jwt/
com/nimbusds/jwt/SignedJWT.class
com/nimbusds/jwt/JWTClaimsSet$Builder.class
com/nimbusds/jwt/package-info.class
{code}
See full output in attachment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19015) hbase-shaded-check-invariants fails against hadoop3-beta1
[
https://issues.apache.org/jira/browse/HBASE-19015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Yu updated HBASE-19015:
---
Attachment: shaded-check-invariants.out
> hbase-shaded-check-invariants fails against hadoop3-beta1
> -
>
> Key: HBASE-19015
> URL: https://issues.apache.org/jira/browse/HBASE-19015
> Project: HBase
> Issue Type: Bug
>Reporter: Ted Yu
> Attachments: shaded-check-invariants.out
>
>
> When using the following command trying to build tar ball against hadoop3
> beta1:
> {code}
> mvn install -DskipTests -Phadoop-3.0 -Dhadoop-three.version=3.0.0-beta1
> -Dhadoop-two.version=3.0.0-beta1 -Djetty.version=9.3.19.v20170502
> assembly:single -Prelease
> {code}
> I got the following:
> {code}
> [ERROR] Found artifact with unexpected contents:
> '/Users/tyu/.m2/repository/org/apache/hbase/hbase-shaded-client/3.0.0-SNAPSHOT/hbase-shaded-client-3.0.0-SNAPSHOT.jar'
> Please check the following and either correct the build or update
> the allowed list with reasoning.
> com/
> com/nimbusds/
> com/nimbusds/jwt/
> com/nimbusds/jwt/SignedJWT.class
> com/nimbusds/jwt/JWTClaimsSet$Builder.class
> com/nimbusds/jwt/package-info.class
> {code}
> See full output in attachment.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205297#comment-16205297
]
Hadoop QA commented on HBASE-18824:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m
12s{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
20s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
25s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
33s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
9s{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
1s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 53s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
52s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
23s{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
8s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 54m 29s{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-18824 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892287/HBASE-18824.master.002.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux f8374e521503 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 202e414 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9126/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output |
https://builds.apache.org/job/PreCommit-HBASE-Build/9126/console |
| Powered by | Apache Yetus 0.4.0 http://yetus.apache.org |
[jira] [Updated] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jerry He updated HBASE-18986:
-
Resolution: Fixed
Hadoop Flags: Reviewed
Fix Version/s: 2.0.0-alpha-4
3.0.0
Status: Resolved (was: Patch Available)
+1
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Fix For: 3.0.0, 2.0.0-alpha-4
>
> Attachments: HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205283#comment-16205283
]
Chia-Ping Tsai commented on HBASE-18824:
{quote}
When the size of Get's result is greater than count (to be deleted), the code
updates the timestamp to server's current time
When the size of Get's result is equal to count(to be deleted), the code
updates the timestamp to the latest version of what could be Get (why?)
{quote}
Region try to find enough PUT cells to update the DELETE cells having the
LATEST_TIMESTAMP. If the number of PUT cells is greater than number of DELETE
cells, it means each DELETE cells have "latest" timestamp provided by real PUT
cell rather than server's ts.
Pardon. I didn't check the comment entirely.
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-18824:
---
Status: Patch Available (was: Reopened)
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19014) surefire fails; When writing xml report stdout/stderr ... No such file or directory
[
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19014:
---
Summary: surefire fails; When writing xml report stdout/stderr ... No such
file or directory (was: surefire fails; When writing xml report stdout/stderr)
> surefire fails; When writing xml report stdout/stderr ... No such file or
> directory
> ---
>
> Key: HBASE-19014
> URL: https://issues.apache.org/jira/browse/HBASE-19014
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
>
> {code}
> 17:22:33 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (secondPartTestsExecution) on project hbase-server: ExecutionException:
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.maven.surefire.report.ReporterException: When writing xml report
> stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
> directory) -> [Help 1]
> {code}
> It happens frequently on my jenkins...I update the surefire to 2.20.1, and
> then the failure don't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19014) surefire fails; When writing xml report stdout/stderr ... No such file or directory
[
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19014:
---
Description:
{code}
17:22:33 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(secondPartTestsExecution) on project hbase-server: ExecutionException:
java.lang.RuntimeException: java.lang.RuntimeException:
org.apache.maven.surefire.report.ReporterException: When writing xml report
stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
directory) -> [Help 1]
{code}
It happens frequently on my jenkins...I update the surefire to 2.20.1, and then
the failure doesn't happen again. see SUREFIRE-1239.
was:
{code}
17:22:33 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(secondPartTestsExecution) on project hbase-server: ExecutionException:
java.lang.RuntimeException: java.lang.RuntimeException:
org.apache.maven.surefire.report.ReporterException: When writing xml report
stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
directory) -> [Help 1]
{code}
It happens frequently on my jenkins...I update the surefire to 2.20.1, and then
the failure don't happen again. see SUREFIRE-1239.
> surefire fails; When writing xml report stdout/stderr ... No such file or
> directory
> ---
>
> Key: HBASE-19014
> URL: https://issues.apache.org/jira/browse/HBASE-19014
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
>
> {code}
> 17:22:33 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (secondPartTestsExecution) on project hbase-server: ExecutionException:
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.maven.surefire.report.ReporterException: When writing xml report
> stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
> directory) -> [Help 1]
> {code}
> It happens frequently on my jenkins...I update the surefire to 2.20.1, and
> then the failure doesn't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-19014) surefire fails; When writing xml report stdout/stderr
[
https://issues.apache.org/jira/browse/HBASE-19014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated HBASE-19014:
---
Fix Version/s: 1.2.7
1.5.0
1.3.2
1.4.0
2.0.0
> surefire fails; When writing xml report stdout/stderr
> -
>
> Key: HBASE-19014
> URL: https://issues.apache.org/jira/browse/HBASE-19014
> Project: HBase
> Issue Type: Bug
>Reporter: Chia-Ping Tsai
> Fix For: 2.0.0, 1.4.0, 1.3.2, 1.5.0, 1.2.7
>
>
> {code}
> 17:22:33 [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
> (secondPartTestsExecution) on project hbase-server: ExecutionException:
> java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.maven.surefire.report.ReporterException: When writing xml report
> stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
> directory) -> [Help 1]
> {code}
> It happens frequently on my jenkins...I update the surefire to 2.20.1, and
> then the failure don't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (HBASE-19014) surefire fails; When writing xml report stdout/stderr
Chia-Ping Tsai created HBASE-19014:
--
Summary: surefire fails; When writing xml report stdout/stderr
Key: HBASE-19014
URL: https://issues.apache.org/jira/browse/HBASE-19014
Project: HBase
Issue Type: Bug
Reporter: Chia-Ping Tsai
{code}
17:22:33 [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-surefire-plugin:2.18.1:test
(secondPartTestsExecution) on project hbase-server: ExecutionException:
java.lang.RuntimeException: java.lang.RuntimeException:
org.apache.maven.surefire.report.ReporterException: When writing xml report
stdout/stderr: /tmp/stderr1114622923250399196deferred (No such file or
directory) -> [Help 1]
{code}
It happens frequently on my jenkins...I update the surefire to 2.20.1, and then
the failure don't happen again. see SUREFIRE-1239.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-18984) [AMv2] Retain assignment does not work well in AMv2
[ https://issues.apache.org/jira/browse/HBASE-18984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205208#comment-16205208 ] Yi Liang commented on HBASE-18984: -- The reason why retain assignment does not work well after disable/enable is that every time we unsign the region, we mark the regionLocation as null in regionStateNode, and when we assign the region, it will load the this null as current region location, and if the region location is null, AM will assign it a random region server to it. Have already fixed above issues, but see other errors when restart cluster. Still debugging. > [AMv2] Retain assignment does not work well in AMv2 > --- > > Key: HBASE-18984 > URL: https://issues.apache.org/jira/browse/HBASE-18984 > Project: HBase > Issue Type: Bug > Components: proc-v2 >Affects Versions: 2.0.0 >Reporter: Yi Liang >Assignee: Yi Liang > Fix For: 2.0.0 > > Attachments: Screen Shot 2017-10-10 at 2.24.19 PM.png > > > work on 8.17 Retain assignment in > https://docs.google.com/document/d/1eVKa7FHdeoJ1-9o8yZcOTAQbv0u0bblBlCCzVSIn69g/edit#heading=h.epjn9nege80k > To reproduce this error, in hbase shell: > createTable t1 --> list_regions 't1' --> disable 't1' ---> enable 't1' --> > list_reigons 't1' (maybe you need to try enable/disable multiple times) > See attached images. same region assigned to different region servers -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205203#comment-16205203 ] Hudson commented on HBASE-18954: FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #3892 (See [https://builds.apache.org/job/HBase-Trunk_matrix/3892/]) HBASE-18954 Make *CoprocessorHost classes private. (appy: rev 202e414eb2e9bf9c825b6ac64a9c2ae50e1dcf5d) * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController3.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverScannerOpenHook.java * (edit) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * (edit) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/coprocessor/Export.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Region.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerCoprocessorHost.java * (edit) hbase-endpoint/src/test/java/org/apache/hadoop/hbase/coprocessor/TestClassLoading.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestWithDisabledAuthorization.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SecureBulkLoadManager.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide3.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch, > HBASE-18954.master.002.patch, HBASE-18954.master.003.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19009) implement enable/disableTableReplication for AsyncAdmin
[
https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205182#comment-16205182
]
Hadoop QA commented on HBASE-19009:
---
| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 12m
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:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m
0s{color} | {color:red} The patch doesn't appear to include any new or modified
tests. Please justify why no new tests are needed for this patch. Also please
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 4m
34s{color} | {color:green} branch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
49s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m
18s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
19s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m
17s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
25s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
10s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green} 3m
59s{color} | {color:green} patch has no errors when building our shaded
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
36m 41s{color} | {color:green} Patch does not cause any errors with Hadoop
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha4. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m
58s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m
18s{color} | {color:red} hbase-client generated 1 new + 2 unchanged - 0 fixed =
3 total (was 2) {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m
29s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
7s{color} | {color:green} The patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 68m 12s{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-19009 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12892292/HBASE-19009.master.001.patch
|
| Optional Tests | asflicense shadedjars javac javadoc unit findbugs
hadoopcheck hbaseanti checkstyle compile |
| uname | Linux 1fc62e686485 3.13.0-119-generic #166-Ubuntu SMP Wed May 3
12:18:55 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
|
| git revision | master / 202e414 |
| Default Java | 1.8.0_144 |
| findbugs | v3.1.0-RC3 |
| javadoc |
https://builds.apache.org/job/PreCommit-HBASE-Build/9125/artifact/patchprocess/diff-javadoc-javadoc-hbase-client.txt
|
| Test Results |
https://builds.apache.org/job/PreCommit-HBASE-Build/9125/testReport/ |
| modules | C:
[jira] [Commented] (HBASE-18990) ServerLoad doesn't override #equals which leads to #equals in ClusterStatus always false
[ https://issues.apache.org/jira/browse/HBASE-18990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205174#comment-16205174 ] Chia-Ping Tsai commented on HBASE-18990: LGTM > ServerLoad doesn't override #equals which leads to #equals in ClusterStatus > always false > > > Key: HBASE-18990 > URL: https://issues.apache.org/jira/browse/HBASE-18990 > Project: HBase > Issue Type: Bug >Reporter: Reid Chan >Assignee: Reid Chan >Priority: Trivial > Fix For: 2.0.0 > > Attachments: HBASE-18990.master.001.patch, > HBASE-18990.master.002.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205160#comment-16205160 ] stack commented on HBASE-19007: --- Makes sense. Yes. > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205158#comment-16205158 ] Hudson commented on HBASE-18954: FAILURE: Integrated in Jenkins build HBase-2.0 #691 (See [https://builds.apache.org/job/HBase-2.0/691/]) HBASE-18954 Make *CoprocessorHost classes private. (appy: rev e04b15c68534500eb7af655a39fd5ae1dec3b3d2) * (edit) hbase-endpoint/src/test/java/org/apache/hadoop/hbase/coprocessor/TestClassLoading.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestWithDisabledAuthorization.java * (edit) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/security/access/SecureBulkLoadEndpoint.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestFromClientSide3.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegionServer.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/Region.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServerCoprocessorHost.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/SecureTestUtil.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/SecureBulkLoadManager.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/coprocessor/CoprocessorHost.java * (edit) hbase-endpoint/src/main/java/org/apache/hadoop/hbase/coprocessor/Export.java * (edit) hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionCoprocessorHost.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/security/access/TestAccessController3.java * (edit) hbase-server/src/test/java/org/apache/hadoop/hbase/coprocessor/TestRegionObserverScannerOpenHook.java > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch, > HBASE-18954.master.002.patch, HBASE-18954.master.003.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19009) implement enable/disableTableReplication for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19009: --- Assignee: Guanghao Zhang Status: Patch Available (was: Open) > implement enable/disableTableReplication for AsyncAdmin > --- > > Key: HBASE-19009 > URL: https://issues.apache.org/jira/browse/HBASE-19009 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19009.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19009) implement enable/disableTableReplication for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205148#comment-16205148 ] Guanghao Zhang commented on HBASE-19009: Will add ut and refactor Admin enable/disableTableReplication methods in next patch. > implement enable/disableTableReplication for AsyncAdmin > --- > > Key: HBASE-19009 > URL: https://issues.apache.org/jira/browse/HBASE-19009 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang >Assignee: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19009.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (HBASE-19009) implement enable/disableTableReplication for AsyncAdmin
[ https://issues.apache.org/jira/browse/HBASE-19009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guanghao Zhang updated HBASE-19009: --- Attachment: HBASE-19009.master.001.patch > implement enable/disableTableReplication for AsyncAdmin > --- > > Key: HBASE-19009 > URL: https://issues.apache.org/jira/browse/HBASE-19009 > Project: HBase > Issue Type: Sub-task >Reporter: Guanghao Zhang > Fix For: 2.0.0-beta-1 > > Attachments: HBASE-19009.master.001.patch > > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205135#comment-16205135
]
Xiang Li commented on HBASE-18824:
--
[~chia7712], would you please review patch 002 at your most convenience?
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Comment Edited] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205135#comment-16205135
]
Xiang Li edited comment on HBASE-18824 at 10/15/17 2:31 PM:
[~chia7712], would you please review patch 002 at your most convenience? Thanks!
was (Author: water):
[~chia7712], would you please review patch 002 at your most convenience?
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18986:
-
Attachment: (was: HBASE-18986.master.000.patch)
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18824) Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is MAX_VALUE
[
https://issues.apache.org/jira/browse/HBASE-18824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiang Li updated HBASE-18824:
-
Attachment: HBASE-18824.master.002.patch
> Add meaningful comment to HConstants.LATEST_TIMESTAMP to explain why it is
> MAX_VALUE
>
>
> Key: HBASE-18824
> URL: https://issues.apache.org/jira/browse/HBASE-18824
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18824.master.000.patch,
> HBASE-18824.master.001.patch, HBASE-18824.master.002.patch
>
>
> Thanks to [Jerry and Chia-Ping Tsai's
> comments|https://issues.apache.org/jira/browse/HBASE-18824?focusedCommentId=16167392=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16167392]
> to correct my wrong understanding.
> The following documentation says that by default(when the timestamp is not
> specified for Put or Delete), system uses the server's {{currentTimeMillis}}.
> 1. In chapter 27.2.4 Put
> bq. Doing a put always creates a new version of a cell, at a certain
> timestamp. {color:#205081}By default the system uses the server’s
> currentTimeMillis{color}, ...
> 2. In chapter 27.2.5 Delete
> bq. Deletes work by creating tombstone markers. For example, let’s suppose we
> want to delete a row. For this you can specify a version, or else
> {color:#205081}by default the currentTimeMillis is used.{color}...
> It seems not consistent with the code. Because in the client side's code,
> when timestamp is not specified, HConstants.LATEST_TIMESTAMP is used, which
> is Long.MAX_VALUE, rather than {{System.currentTimeMillis()}}.
> However, the documentation is correct, because on the server side, timestamp
> of Put cell with HConstants.LATEST_TIMESTAMP will be replaced with server's
> {{currentTimeMillis}}.
> So we decide to add more comments to HConstants.LATEST_TIMESTAMP to help the
> new comers steer clear of the confusion.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Appy updated HBASE-18954: - Resolution: Fixed Status: Resolved (was: Patch Available) > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch, > HBASE-18954.master.002.patch, HBASE-18954.master.003.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205091#comment-16205091 ] Appy commented on HBASE-18954: -- Thanks for the review [~anoop.hbase]. Pushed to master and branch-2. > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch, > HBASE-18954.master.002.patch, HBASE-18954.master.003.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-19005) Mutation batch should not accept operations with different durabilities
[ https://issues.apache.org/jira/browse/HBASE-19005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205074#comment-16205074 ] Anoop Sam John commented on HBASE-19005: That says users are using this way already and we can not do such BC break in client side Public APIs right? > Mutation batch should not accept operations with different durabilities > --- > > Key: HBASE-19005 > URL: https://issues.apache.org/jira/browse/HBASE-19005 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 2.0.0-alpha-3 >Reporter: Umesh Agashe >Assignee: Umesh Agashe > Fix For: 2.0.0-beta-1 > > > Javadoc and change client side API to not accept operations with different > durabilities in a mutation batch. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18954) Make *CoprocessorHost classes private
[ https://issues.apache.org/jira/browse/HBASE-18954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205071#comment-16205071 ] Anoop Sam John commented on HBASE-18954: +1 > Make *CoprocessorHost classes private > - > > Key: HBASE-18954 > URL: https://issues.apache.org/jira/browse/HBASE-18954 > Project: HBase > Issue Type: Sub-task > Components: Coprocessors >Reporter: Appy >Assignee: Appy > Labels: incompatible > Fix For: 2.0.0-alpha-4 > > Attachments: HBASE-18954.master.001.patch, > HBASE-18954.master.002.patch, HBASE-18954.master.003.patch > > > Move out configuration name constants (into Coprocessor class?) and made Host > classes private. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (HBASE-18986) Remove unnecessary null check after CellUtil.cloneQualifier()
[
https://issues.apache.org/jira/browse/HBASE-18986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205060#comment-16205060
]
Xiang Li commented on HBASE-18986:
--
[~jerryhe], thanks, Hadoop QA is triggered and there is no UT error.
> Remove unnecessary null check after CellUtil.cloneQualifier()
> -
>
> Key: HBASE-18986
> URL: https://issues.apache.org/jira/browse/HBASE-18986
> Project: HBase
> Issue Type: Improvement
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Minor
> Attachments: HBASE-18986.master.000.patch,
> HBASE-18986.master.000.patch
>
>
> In master branch,
> {code:title=hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java|borderStyle=solid}
> // From line 2858
> public void prepareDeleteTimestamps(Mutation mutation, Map List> familyMap,
> byte[] byteNow) throws IOException {
> for (Map.Entry e : familyMap.entrySet()) {
> // ...
> for (int i=0; i < listSize; i++) {
> // ...
> if (cell.getTimestamp() == HConstants.LATEST_TIMESTAMP &&
> CellUtil.isDeleteType(cell)) {
> byte[] qual = CellUtil.cloneQualifier(cell);
> if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY; // <-- here
> ...
> {code}
> Might {{if (qual == null) qual = HConstants.EMPTY_BYTE_ARRAY;}} be removed?
> Could it be null after CellUtil.cloneQualifier()?
> {code:title=hbase-common/src/main/java/org/apache/hadoop/hbase/CellUtil.java|borderStyle=solid}
> public static byte[] cloneQualifier(Cell cell){
> byte[] output = new byte[cell.getQualifierLength()];
> copyQualifierTo(cell, output, 0);
> return output;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (HBASE-19007) Align Services Interfaces in Master and RegionServer
[ https://issues.apache.org/jira/browse/HBASE-19007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16205059#comment-16205059 ] Anoop Sam John commented on HBASE-19007: bq./ in RegionServerCoprocessorEnvironment and ditton in MasterCoprocessorEnvironment, bq.we'd instead make availalble as a method on RegionServerCoprocessorEnvironment Got it. Also to be to RegionCoprocessorEnvironment ? That is what we will get at CP hooks which act on region (like prePut etc).. Also WALCoprocessorEnvironment? > Align Services Interfaces in Master and RegionServer > > > Key: HBASE-19007 > URL: https://issues.apache.org/jira/browse/HBASE-19007 > Project: HBase > Issue Type: Task >Reporter: stack >Priority: Blocker > > HBASE-18183 adds a CoprocessorRegionServerService to give a view on > RegionServiceServices that is safe to expose to Coprocessors. > On the Master-side, MasterServices becomes an Interface for exposing to > Coprocessors. > We need to align the two. > For background, see > https://issues.apache.org/jira/browse/HBASE-12260?focusedCommentId=16203820=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16203820 > -- This message was sent by Atlassian JIRA (v6.4.14#64029)
