[jira] [Commented] (HBASE-15365) Do not write to '/tmp' in TestHBaseConfiguration
[
https://issues.apache.org/jira/browse/HBASE-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173407#comment-15173407
]
Hadoop QA commented on HBASE-15365:
---
| (/) *{color:green}+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: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} 4m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 25s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 23s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
28s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 0s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 26s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
24s {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_72 {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 22s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 22s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
35m 37s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 8s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 25s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 24s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 38s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 27s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
11s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 56m 25s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-03-01 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790680/HBASE-15365.patch |
| JIRA Issue | HBASE-15365 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 6022b6d04c80 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality |
[jira] [Commented] (HBASE-14932) bulkload fails because file not found
[
https://issues.apache.org/jira/browse/HBASE-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173371#comment-15173371
]
Hadoop QA commented on HBASE-14932:
---
| (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: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} 4m
39s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} 0.98 passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 32s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
21s {color} | {color:green} 0.98 passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} 0.98 passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 55s
{color} | {color:red} hbase-server in 0.98 has 84 extant Findbugs warnings.
{color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 31s
{color} | {color:red} hbase-server in 0.98 failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} 0.98 passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
39s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m
16s {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:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 0s
{color} | {color:red} The patch has 1 line(s) that end in whitespace. Use git
apply --whitespace=fix. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 4m
12s {color} | {color:green} Patch does not cause any errors with Hadoop 2.4.1
2.5.2 2.6.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 6s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 29s
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 60m 2s
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 62m 5s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
21s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 156m 3s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-03-01 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12789142/HBASE-14932-0.98.patch
|
| JIRA Issue | HBASE-14932 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 2643e55f3661
[jira] [Commented] (HBASE-15265) Implement an asynchronous FSHLog
[
https://issues.apache.org/jira/browse/HBASE-15265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173350#comment-15173350
]
Hadoop QA commented on HBASE-15265:
---
| (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: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 14 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
5s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 38s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
22s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 3s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
47s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 41s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 3m 59s
{color} | {color:red} Patch generated 24 new checkstyle issues in hbase-server
(total was 114, now 112). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
27m 27s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 62m 27s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 103m 29s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
17s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 216m 7s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.snapshot.TestSnapshotClientRetries |
| | org.apache.hadoop.hbase.master.balancer.TestStochasticLoadBalancer2 |
| | org.apache.hadoop.hbase.master.TestMasterFailover |
| | org.apache.hadoop.hbase.coprocessor.TestRegionObserverScannerOpenHook |
| | org.apache.hadoop.hbase.namespace.TestNamespaceAuditor |
| | org.apache.hadoop.hbase.wal.TestWALFiltering |
| |
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[
https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173351#comment-15173351
]
Anoop Sam John commented on HBASE-15321:
So what you observed is taking direct HDFS snapshot helps in time taken for
this snapshot op in setup.
As it is scan over region directly, it can use HBase kind of optimization like
time range check on files. Make sense. Now I get why u want to use this way
rather than MR over snapshot.
But on the patch, do we really need these changes? We already have states
like readOnly, readEnabled, writeEnabled.. Adding one more read related makes
things more confusing IMO.
{code}
HRegion r = HRegion.newHRegion(tableDir, wal, fs, conf, info, htd, null);
6361return r.openHRegion(null);
{code}
U can have this code in ur setup. Make the HRegionInfo to set it as a non
primary replica id.. Yes this HRegion instance will give out of date data just
like non primary replicas. Setting to non primary make it to be readOnly.
bq.this.writestate.setReadOnly(ServerRegionReplicaUtil.isReadOnly(this));
Am I missing some other things?
> Ability to open a HRegion from hdfs snapshot.
> -
>
> Key: HBASE-15321
> URL: https://issues.apache.org/jira/browse/HBASE-15321
> Project: HBase
> Issue Type: New Feature
>Affects Versions: 2.0.0
>Reporter: churro morales
> Fix For: 2.0.0
>
> Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch,
> HBASE-15321-v3.patch, HBASE-15321.patch
>
>
> Now that hdfs snapshots are here, we started to run our mapreduce jobs over
> hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time
> copies of the file system. Thus we had to modify the section of code that
> initialized the region internals in HRegion. We have to skip cleanup of
> certain directories if the HRegion is backed by a hdfs snapshot. I have a
> patch for trunk with some basic tests if folks are interested.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15366) Add doc, trace-level logging, and test around hfileblock
[ https://issues.apache.org/jira/browse/HBASE-15366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15366: -- Fix Version/s: 2.0.0 Affects Version/s: 2.0.0 Status: Patch Available (was: Open) > Add doc, trace-level logging, and test around hfileblock > > > Key: HBASE-15366 > URL: https://issues.apache.org/jira/browse/HBASE-15366 > Project: HBase > Issue Type: Sub-task > Components: BlockCache >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: 15366.patch > > > What hfileblock is doing -- that it overreads when pulling in from hdfs to > fetch the header of the next block to save on seeks; that it caches the block > and overread and then adds an extra 13 bytes to the cached entry; that > buckets in bucketcache have at least four hfileblocks in them and so on -- > was totally baffling me. This patch docs the class, adds some trace-level > logging so you can see if you are doing the right thing, and then adds a test > of file-backed bucketcache that checks that persistence is working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15366) Add doc, trace-level logging, and test around hfileblock
[ https://issues.apache.org/jira/browse/HBASE-15366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15366: -- Attachment: 15366.patch No change in behavior. Just doc really. > Add doc, trace-level logging, and test around hfileblock > > > Key: HBASE-15366 > URL: https://issues.apache.org/jira/browse/HBASE-15366 > Project: HBase > Issue Type: Sub-task > Components: BlockCache >Affects Versions: 2.0.0 >Reporter: stack >Assignee: stack > Fix For: 2.0.0 > > Attachments: 15366.patch > > > What hfileblock is doing -- that it overreads when pulling in from hdfs to > fetch the header of the next block to save on seeks; that it caches the block > and overread and then adds an extra 13 bytes to the cached entry; that > buckets in bucketcache have at least four hfileblocks in them and so on -- > was totally baffling me. This patch docs the class, adds some trace-level > logging so you can see if you are doing the right thing, and then adds a test > of file-backed bucketcache that checks that persistence is working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14921) Memory optimizations
[ https://issues.apache.org/jira/browse/HBASE-14921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173339#comment-15173339 ] ramkrishna.s.vasudevan commented on HBASE-14921: [~saint@gmail.com] bq.Should we move the MSLAB forward so when we pull form the socket on the read of requests, we read into an MSLAB Do you see some benefit over here? bq.So, when you say the MSLAB can be offheap, its ok to have references only in CSLM? We do not want to be copying data across the onheap/offheap boundary if it can be avoided. We can do compare offheap The current scope of offheaping will only do this. (sorry for me replying here). Offheap references will be in CSLM. I think with CSLM more the data in CSLM the more the comparisons in sorting the CSLM. (may be am wrong here?). So moving to array and a sorted one will make searching easier makes sense. i think this is going to be done after copying over to a new MSLAB. bq.No. We are going to allocate the array of Cells for the worst case - all the cells will survive. Worth doing I think. > Memory optimizations > > > Key: HBASE-14921 > URL: https://issues.apache.org/jira/browse/HBASE-14921 > Project: HBase > Issue Type: Sub-task >Affects Versions: 2.0.0 >Reporter: Eshcar Hillel >Assignee: Anastasia Braginsky > Attachments: CellBlocksSegmentInMemStore.pdf > > > Memory optimizations including compressed format representation and offheap > allocations -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15365) Do not write to '/tmp' in TestHBaseConfiguration
[ https://issues.apache.org/jira/browse/HBASE-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15365: -- Status: Patch Available (was: Open) > Do not write to '/tmp' in TestHBaseConfiguration > > > Key: HBASE-15365 > URL: https://issues.apache.org/jira/browse/HBASE-15365 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15365.patch > > > In testGetPassword, we create a key file at /tmp/foo.jks and set its > permissions to 600. This will cause testcase failure on a shared machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15365) Do not write to '/tmp' in TestHBaseConfiguration
[ https://issues.apache.org/jira/browse/HBASE-15365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15365: -- Attachment: HBASE-15365.patch A trivial fix. Just write to a tmp directory and delete the directoty after test. > Do not write to '/tmp' in TestHBaseConfiguration > > > Key: HBASE-15365 > URL: https://issues.apache.org/jira/browse/HBASE-15365 > Project: HBase > Issue Type: Bug > Components: test >Reporter: Duo Zhang >Assignee: Duo Zhang > Attachments: HBASE-15365.patch > > > In testGetPassword, we create a key file at /tmp/foo.jks and set its > permissions to 600. This will cause testcase failure on a shared machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15366) Add doc, trace-level logging, and test around hfileblock
stack created HBASE-15366: - Summary: Add doc, trace-level logging, and test around hfileblock Key: HBASE-15366 URL: https://issues.apache.org/jira/browse/HBASE-15366 Project: HBase Issue Type: Sub-task Components: BlockCache Reporter: stack Assignee: stack What hfileblock is doing -- that it overreads when pulling in from hdfs to fetch the header of the next block to save on seeks; that it caches the block and overread and then adds an extra 13 bytes to the cached entry; that buckets in bucketcache have at least four hfileblocks in them and so on -- was totally baffling me. This patch docs the class, adds some trace-level logging so you can see if you are doing the right thing, and then adds a test of file-backed bucketcache that checks that persistence is working. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15365) Do not write to '/tmp' in TestHBaseConfiguration
Duo Zhang created HBASE-15365: - Summary: Do not write to '/tmp' in TestHBaseConfiguration Key: HBASE-15365 URL: https://issues.apache.org/jira/browse/HBASE-15365 Project: HBase Issue Type: Bug Components: test Reporter: Duo Zhang Assignee: Duo Zhang In testGetPassword, we create a key file at /tmp/foo.jks and set its permissions to 600. This will cause testcase failure on a shared machine. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15349) Update surefire version to 2.19.1
[ https://issues.apache.org/jira/browse/HBASE-15349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack updated HBASE-15349: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) Seems good. We are running more tests now since this patch went in (smile). I'd worry if we were doing less. Thanks [~appy] > Update surefire version to 2.19.1 > - > > Key: HBASE-15349 > URL: https://issues.apache.org/jira/browse/HBASE-15349 > Project: HBase > Issue Type: Improvement >Reporter: Appy >Assignee: Appy > Fix For: 2.0.0 > > Attachments: HBASE-15349.patch > > > So that new properties like surefire.excludesFile and includesFile can be > used to easily exclude/include flaky tests. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15361) Remove unnecessary or Document constraints on BucketCache possible bucket sizes
[
https://issues.apache.org/jira/browse/HBASE-15361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173309#comment-15173309
]
Anoop Sam John commented on HBASE-15361:
There is a long state for accessCount as well.. Said that, this saving of 3
bytes is not much.. We should try to reduce other bigger things then. IMO
> Remove unnecessary or Document constraints on BucketCache possible bucket
> sizes
>
>
> Key: HBASE-15361
> URL: https://issues.apache.org/jira/browse/HBASE-15361
> Project: HBase
> Issue Type: Sub-task
> Components: BucketCache
>Reporter: deepankar
>Priority: Minor
>
> When we were trying to tune the bucket sizes
> {{hbase.bucketcache.bucket.sizes}} according to our workload, we encountered
> an issue due to the way offset is stored in the bucket entry. We divide the
> offset into integer base and byte value and it assumes that all bucket
> offsets will be a multiple of 256 (left shifting by 8). See the code below
> {code}
> long offset() { // Java has no unsigned numbers
> long o = ((long) offsetBase) & 0x;
> o += (((long) (offset1)) & 0xFF) << 32;
> return o << 8;
> }
> private void setOffset(long value) {
> assert (value & 0xFF) == 0;
> value >>= 8;
> offsetBase = (int) value;
> offset1 = (byte) (value >> 32);
> }
> {code}
> This was there to save 3 bytes per BucketEntry instead of using long and when
> there are no other fields in the Bucket Entry, but now there are lot of
> fields in the bucket entry , This not documented so we could either document
> the constraint that it should be a strict 256 bytes multiple of just go away
> with this constraint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-15325) ResultScanner allowing partial result will miss the rest of the row if the region is moved between two rpc requests
[ https://issues.apache.org/jira/browse/HBASE-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Yang updated HBASE-15325: -- Attachment: HBASE-15325-v6.txt Fix typo according to review and add more assert on isPartial to detect bug. Test can pass in my own computer but fail in PreCommit-HBASE-Build. > ResultScanner allowing partial result will miss the rest of the row if the > region is moved between two rpc requests > --- > > Key: HBASE-15325 > URL: https://issues.apache.org/jira/browse/HBASE-15325 > Project: HBase > Issue Type: Bug >Affects Versions: 1.2.0, 1.1.3 >Reporter: Phil Yang >Assignee: Phil Yang >Priority: Critical > Attachments: 15325-test.txt, HBASE-15325-v1.txt, HBASE-15325-v2.txt, > HBASE-15325-v3.txt, HBASE-15325-v5.txt, HBASE-15325-v6.txt > > > HBASE-11544 allow scan rpc return partial of a row to reduce memory usage for > one rpc request. And client can setAllowPartial or setBatch to get several > cells in a row instead of the whole row. > However, the status of the scanner is saved on server and we need this to get > the next part if there is a partial result before. If we move the region to > another RS, client will get a NotServingRegionException and open a new > scanner to the new RS which will be regarded as a new scan from the end of > this row. So the rest cells of the row of last result will be missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15361) Remove unnecessary or Document constraints on BucketCache possible bucket sizes
[
https://issues.apache.org/jira/browse/HBASE-15361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173299#comment-15173299
]
ramkrishna.s.vasudevan commented on HBASE-15361:
bq.Ya we have many more states now.
What are the new states added now?
{code}
private volatile boolean markedForEvict;
private AtomicInteger refCount = new AtomicInteger(0);
{code}
These two were added recently I think.
> Remove unnecessary or Document constraints on BucketCache possible bucket
> sizes
>
>
> Key: HBASE-15361
> URL: https://issues.apache.org/jira/browse/HBASE-15361
> Project: HBase
> Issue Type: Sub-task
> Components: BucketCache
>Reporter: deepankar
>Priority: Minor
>
> When we were trying to tune the bucket sizes
> {{hbase.bucketcache.bucket.sizes}} according to our workload, we encountered
> an issue due to the way offset is stored in the bucket entry. We divide the
> offset into integer base and byte value and it assumes that all bucket
> offsets will be a multiple of 256 (left shifting by 8). See the code below
> {code}
> long offset() { // Java has no unsigned numbers
> long o = ((long) offsetBase) & 0x;
> o += (((long) (offset1)) & 0xFF) << 32;
> return o << 8;
> }
> private void setOffset(long value) {
> assert (value & 0xFF) == 0;
> value >>= 8;
> offsetBase = (int) value;
> offset1 = (byte) (value >> 32);
> }
> {code}
> This was there to save 3 bytes per BucketEntry instead of using long and when
> there are no other fields in the Bucket Entry, but now there are lot of
> fields in the bucket entry , This not documented so we could either document
> the constraint that it should be a strict 256 bytes multiple of just go away
> with this constraint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15361) Remove unnecessary or Document constraints on BucketCache possible bucket sizes
[
https://issues.apache.org/jira/browse/HBASE-15361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173268#comment-15173268
]
Anoop Sam John commented on HBASE-15361:
Ya I have also observed this recently. (When checking a bug reported in
BucketCache). Ya we have many more states now.. I don't think we need to try
to save 3 bytes this way. cc [~saint@gmail.com]
> Remove unnecessary or Document constraints on BucketCache possible bucket
> sizes
>
>
> Key: HBASE-15361
> URL: https://issues.apache.org/jira/browse/HBASE-15361
> Project: HBase
> Issue Type: Sub-task
> Components: BucketCache
>Reporter: deepankar
>Priority: Minor
>
> When we were trying to tune the bucket sizes
> {{hbase.bucketcache.bucket.sizes}} according to our workload, we encountered
> an issue due to the way offset is stored in the bucket entry. We divide the
> offset into integer base and byte value and it assumes that all bucket
> offsets will be a multiple of 256 (left shifting by 8). See the code below
> {code}
> long offset() { // Java has no unsigned numbers
> long o = ((long) offsetBase) & 0x;
> o += (((long) (offset1)) & 0xFF) << 32;
> return o << 8;
> }
> private void setOffset(long value) {
> assert (value & 0xFF) == 0;
> value >>= 8;
> offsetBase = (int) value;
> offset1 = (byte) (value >> 32);
> }
> {code}
> This was there to save 3 bytes per BucketEntry instead of using long and when
> there are no other fields in the Bucket Entry, but now there are lot of
> fields in the bucket entry , This not documented so we could either document
> the constraint that it should be a strict 256 bytes multiple of just go away
> with this constraint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173243#comment-15173243 ] Anoop Sam John commented on HBASE-15180: So in this patch made sure that on client side we wont go with optimization of Cells created directly over the response read buffer. The cells will be handed over to user app and we can not be sure whether some of the cells will be cached or not. Caching even single cell will make it such that we can not GC the bigger sized response buffer. Server side we have MSLAB and copy to that before adding Cells to memstore. [~enis] Ping for ur review as well. > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch, HBASE-15180_V7.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15180) Reduce garbage created while reading Cells from Codec Decoder
[ https://issues.apache.org/jira/browse/HBASE-15180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-15180: --- Attachment: HBASE-15180_V7.patch > Reduce garbage created while reading Cells from Codec Decoder > - > > Key: HBASE-15180 > URL: https://issues.apache.org/jira/browse/HBASE-15180 > Project: HBase > Issue Type: Sub-task > Components: regionserver >Affects Versions: 0.98.0 >Reporter: Anoop Sam John >Assignee: Anoop Sam John > Fix For: 2.0.0 > > Attachments: HBASE-15180.patch, HBASE-15180_V2.patch, > HBASE-15180_V4.patch, HBASE-15180_V6.patch, HBASE-15180_V7.patch > > > In KeyValueDecoder#parseCell (Default Codec decoder) we use > KeyValueUtil#iscreate to read cells from the InputStream. Here we 1st create > a byte[] of length 4 and read the cell length and then an array of Cell's > length and read in cell bytes into it and create a KV. > Actually in server we read the reqs into a byte[] and CellScanner is created > on top of a ByteArrayInputStream on top of this. By default in write path, we > have MSLAB usage ON. So while adding Cells to memstore, we will copy the Cell > bytes to MSLAB memory chunks (default 2 MB size) and recreate Cells over that > bytes. So there is no issue if we create Cells over the RPC read byte[] > directly here in Decoder. No need for 2 byte[] creation and copy for every > Cell in request. > My plan is to make a Cell aware ByteArrayInputStream which can read Cells > directly from it. > Same Codec path is used in client side also. There better we can avoid this > direct Cell create and continue to do the copy to smaller byte[]s path. Plan > to introduce some thing like a CodecContext associated with every Codec > instance which can say the server/client context. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14932) bulkload fails because file not found
[ https://issues.apache.org/jira/browse/HBASE-14932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shuaifeng Zhou updated HBASE-14932: --- Status: Patch Available (was: Open) > bulkload fails because file not found > - > > Key: HBASE-14932 > URL: https://issues.apache.org/jira/browse/HBASE-14932 > Project: HBase > Issue Type: Bug > Components: regionserver >Affects Versions: 0.98.10 >Reporter: Shuaifeng Zhou >Assignee: Alicia Ying Shu > Fix For: 0.98.18 > > Attachments: HBASE-14932-0.98.patch > > > When make a dobulkload call, one call may contain sevel hfiles to load, but > the call may timeout during regionserver load files, and client will retry to > load. > But when client doing retry call, regionserver may continue doing load > operation, if somefiles success, the retry call will throw filenotfound > exception, and this will cause client retry again and again until retry > exhausted, and bulkload fails. > When this happening, actually, some files are loaded successfully, that's a > inconsistent status. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173192#comment-15173192 ] Hudson commented on HBASE-15323: FAILURE: Integrated in HBase-1.3 #581 (See [https://builds.apache.org/job/HBase-1.3/581/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev a9dd9c7b8286ec07e4ba37c467ed0bb2c6298a1b) * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15339) Add archive tiers for date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173181#comment-15173181 ] Duo Zhang commented on HBASE-15339: --- For example, usually we consider hot data to be 'data that written in the last 7 days', not 'data that written after last Monday', that's why a moving window is more suitable to determine hot data. And for the archive logic, there is a max age config which we will skip compaction on files older than this. I think we could do archive on these files? Thanks. > Add archive tiers for date based tiered compaction > -- > > Key: HBASE-15339 > URL: https://issues.apache.org/jira/browse/HBASE-15339 > Project: HBase > Issue Type: Improvement > Components: Compaction >Reporter: Duo Zhang > > For our MiCloud service, the old data is rarely touched but we still need to > keep it, so we want to put the data on inexpensive device and reduce > redundancy using EC to cut down the cost. > With date based tiered compaction introduced in HBASE-15181, new data and old > data can be placed in different tier. But the tier boundary moves as time > lapse so it is still possible that we do compaction on old tier which breaks > our block moving and EC work. > So here we want to introduce an "archive tier" to better fit our scenario. > Add an configuration called "archive unit", for example, year. That means, if > we find that the tier boundary is already in the previous year, then we reset > the boundary to the start of year and end of year, and if we want to do > compaction in this tier, just compact all files into one file. The file will > never be changed unless we force a major compaction so it is safe to apply EC > and other cost reducing approach on the file. And we make more tiers before > this tier year by year. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15265) Implement an asynchronous FSHLog
[ https://issues.apache.org/jira/browse/HBASE-15265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Duo Zhang updated HBASE-15265: -- Attachment: HBASE-15265-v5.patch Forget to reset highestUnsyncedSequence... > Implement an asynchronous FSHLog > > > Key: HBASE-15265 > URL: https://issues.apache.org/jira/browse/HBASE-15265 > Project: HBase > Issue Type: Sub-task > Components: wal >Reporter: Duo Zhang >Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15265-v1.patch, HBASE-15265-v2.patch, > HBASE-15265-v3.patch, HBASE-15265-v4.patch, HBASE-15265-v5.patch, > HBASE-15265.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15357) TableInputFormatBase getSplitKey does not handle signed bytes correctly
[
https://issues.apache.org/jira/browse/HBASE-15357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173160#comment-15173160
]
Nathan Schile commented on HBASE-15357:
---
For reference the current code returns a split point of -4, when the split
point should be 124.
{code}
byte[] start = { 120 }; // 'x'
byte[] end = { -128 }; // '€'
byte[] splitPoint = { -4 };
{code}
> TableInputFormatBase getSplitKey does not handle signed bytes correctly
> ---
>
> Key: HBASE-15357
> URL: https://issues.apache.org/jira/browse/HBASE-15357
> Project: HBase
> Issue Type: Bug
> Components: mapreduce
>Reporter: Nathan Schile
>Assignee: Nathan Schile
> Attachments: HBASE-15357.patch
>
>
> When auto-balance is enabled in TableInputFormatBase and the table key is a
> binary key, the getSplitKey method does not function correctly for signed
> bytes. The proposed solution it to utilize
> org.apache.hadoop.hbase.util.Bytes#split method to find the split key.
> org.apache.hadoop.hbase.util.Bytes#split is stated to be a expensive
> operation, so if another solution is preferred, that is fine. In addition,
> handling of a split key that is equal to the TableSplit end key is added to
> calculateRebalancedSplits.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Vimont updated HBASE-14877: -- Fix Version/s: 1.3.0 > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173116#comment-15173116 ] Daniel Vimont commented on HBASE-14877: --- Okay, I just added "1.3.0" to the fix-versions for this JIRA entry. > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173100#comment-15173100 ] Hudson commented on HBASE-15323: SUCCESS: Integrated in HBase-1.2 #566 (See [https://builds.apache.org/job/HBase-1.2/566/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev a0301dcacf5793b865ba63f370cc44d2a2d516e0) * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15354) Use same criteria for clearing meta cache for all operations
[ https://issues.apache.org/jira/browse/HBASE-15354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15354: Affects Version/s: 1.3.0 > Use same criteria for clearing meta cache for all operations > > > Key: HBASE-15354 > URL: https://issues.apache.org/jira/browse/HBASE-15354 > Project: HBase > Issue Type: Bug > Components: Client >Affects Versions: 2.0.0, 1.2.0, 1.3.0 >Reporter: Ashu Pachauri >Assignee: Ashu Pachauri > Attachments: HBASE-15354-V0.patch, HBASE-15354-V1.patch > > > Currently we do not clear/update meta cache for some special exceptions if > the operation went through AsyncProcess#submit like HTable#put calls. But, we > clear meta cache without checking for these special exceptions in case of > other operations like gets, deletes etc because they directly go through the > RpcRetryingCaller#callWithRetries instead of the AsyncProcess. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173045#comment-15173045 ] Mikhail Antonov commented on HBASE-14877: - I'd say - only open a new jira if backporting is some actual work; if cherry-picking from master applies with no errors, there's probably no need to open a separate jira for that. > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Fix For: 2.0.0 > > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-6721) RegionServer Group based Assignment
[
https://issues.apache.org/jira/browse/HBASE-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173041#comment-15173041
]
Enis Soztutar commented on HBASE-6721:
--
bq. Need to address circular dependecy between hbase-rsgroup and hbase-server.
Since the MasterObserver CP has hooks into the GroupAdminEndpoint.
If it is a strict "no" on the RS Group coprocessor reaching out to the
internals of AccessController (as per above comment from [~apurtell]), then the
only option is to add the rs group specific methods to the base MasterObserver.
I think it is acceptable since they would be empty method declarations if the
module is not used.
For the ServerName change, this parts seems relevant (from
ServerName.parseFrom()):
{code}
// The str returned could be old style -- pre hbase-1502 -- which was
// hostname and port seperated by a colon rather than hostname, port and
// startcode delimited by a ','.
{code}
HBASE-1502 is committed around 0.92 timeframe, so I am not sure whether we will
have any such server name strings around anymore.
> RegionServer Group based Assignment
> ---
>
> Key: HBASE-6721
> URL: https://issues.apache.org/jira/browse/HBASE-6721
> Project: HBase
> Issue Type: New Feature
>Reporter: Francis Liu
>Assignee: Francis Liu
> Labels: hbase-6721
> Attachments: 6721-master-webUI.patch, HBASE-6721
> GroupBasedLoadBalancer Sequence Diagram.xml, HBASE-6721-DesigDoc.pdf,
> HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf, HBASE-6721-DesigDoc.pdf,
> HBASE-6721_0.98_2.patch, HBASE-6721_10.patch, HBASE-6721_11.patch,
> HBASE-6721_12.patch, HBASE-6721_13.patch, HBASE-6721_14.patch,
> HBASE-6721_15.patch, HBASE-6721_8.patch, HBASE-6721_9.patch,
> HBASE-6721_9.patch, HBASE-6721_94.patch, HBASE-6721_94.patch,
> HBASE-6721_94_2.patch, HBASE-6721_94_3.patch, HBASE-6721_94_3.patch,
> HBASE-6721_94_4.patch, HBASE-6721_94_5.patch, HBASE-6721_94_6.patch,
> HBASE-6721_94_7.patch, HBASE-6721_98_1.patch, HBASE-6721_98_2.patch,
> HBASE-6721_hbase-6721_addendum.patch, HBASE-6721_trunk.patch,
> HBASE-6721_trunk.patch, HBASE-6721_trunk.patch, HBASE-6721_trunk1.patch,
> HBASE-6721_trunk2.patch, balanceCluster Sequence Diagram.svg,
> hbase-6721-v15-branch-1.1.patch, hbase-6721-v16.patch, hbase-6721-v17.patch,
> hbase-6721-v18.patch, hbase-6721-v19.patch, hbase-6721-v20.patch,
> hbase-6721-v21.patch, hbase-6721-v22.patch, hbase-6721-v23.patch,
> hbase-6721-v25.patch, hbase-6721-v26_draft1.patch, immediateAssignments
> Sequence Diagram.svg, randomAssignment Sequence Diagram.svg, retainAssignment
> Sequence Diagram.svg, roundRobinAssignment Sequence Diagram.svg
>
>
> In multi-tenant deployments of HBase, it is likely that a RegionServer will
> be serving out regions from a number of different tables owned by various
> client applications. Being able to group a subset of running RegionServers
> and assign specific tables to it, provides a client application a level of
> isolation and resource allocation.
> The proposal essentially is to have an AssignmentManager which is aware of
> RegionServer groups and assigns tables to region servers based on groupings.
> Load balancing will occur on a per group basis as well.
> This is essentially a simplification of the approach taken in HBASE-4120. See
> attached document.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14877) maven archetype: client application
[ https://issues.apache.org/jira/browse/HBASE-14877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15173018#comment-15173018 ] Daniel Vimont commented on HBASE-14877: --- [~mantonov] -- this would be the first archetype-related patch to backport to branch-1. (HBASE-14878 is dependent upon this one.) I'm not sure whether it's appropriate to add a new "fixVersion" value to this JIRA issue, or to create a new JIRA that refers back to this one (as [~busbey] advises in the comment above that he posted 27-Jan-13:07). Let me know of any way I might be of assistance with the backport process. > maven archetype: client application > --- > > Key: HBASE-14877 > URL: https://issues.apache.org/jira/browse/HBASE-14877 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: archetype, beginner, maven > Fix For: 2.0.0 > > Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, > HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, > HBASE-14877.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-15345) add branch-1.3 post-commit builds
[ https://issues.apache.org/jira/browse/HBASE-15345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15345 started by Mikhail Antonov. --- > add branch-1.3 post-commit builds > - > > Key: HBASE-15345 > URL: https://issues.apache.org/jira/browse/HBASE-15345 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15345) add branch-1.3 post-commit builds
[ https://issues.apache.org/jira/browse/HBASE-15345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172978#comment-15172978 ] Mikhail Antonov commented on HBASE-15345: - Thanks! - I'll ask ASF builds/Infra guys then. > add branch-1.3 post-commit builds > - > > Key: HBASE-15345 > URL: https://issues.apache.org/jira/browse/HBASE-15345 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15345) add branch-1.3 post-commit builds
[ https://issues.apache.org/jira/browse/HBASE-15345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172970#comment-15172970 ] Andrew Purtell commented on HBASE-15345: I'm not familiar with any special PMC thing that needs to be done with Jenkins. We do group membership, and PMC karma. Contact builds? 'antonov' is a member of the HBase UNIX group (and not a member of the PMC group, obviously) > add branch-1.3 post-commit builds > - > > Key: HBASE-15345 > URL: https://issues.apache.org/jira/browse/HBASE-15345 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172969#comment-15172969 ] Hudson commented on HBASE-15323: SUCCESS: Integrated in HBase-1.1-JDK8 #1759 (See [https://builds.apache.org/job/HBase-1.1-JDK8/1759/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev 58f0bb52f1e29493f2e43a2f2769183ac802145a) * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172926#comment-15172926 ] Hudson commented on HBASE-15323: FAILURE: Integrated in HBase-Trunk_matrix #747 (See [https://builds.apache.org/job/HBase-Trunk_matrix/747/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev 7c54525c89bbbe0c66401813433bfb957e461eac) * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15346) add 1.3 RM to docs
[ https://issues.apache.org/jira/browse/HBASE-15346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172925#comment-15172925 ] Hudson commented on HBASE-15346: FAILURE: Integrated in HBase-Trunk_matrix #747 (See [https://builds.apache.org/job/HBase-Trunk_matrix/747/]) HBASE-15346 add 1.3 RM to docs (antonov: rev bc112888ef557e7d6bf0cc9e91c0d6d63d4f89f9) * src/main/asciidoc/_chapters/developer.adoc > add 1.3 RM to docs > -- > > Key: HBASE-15346 > URL: https://issues.apache.org/jira/browse/HBASE-15346 > Project: HBase > Issue Type: Sub-task > Components: documentation >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0 > > Attachments: HBASE-15346.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172923#comment-15172923 ] Hudson commented on HBASE-15323: FAILURE: Integrated in HBase-1.1-JDK7 #1673 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1673/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev 58f0bb52f1e29493f2e43a2f2769183ac802145a) * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15295) MutateTableAccess.multiMutate() does not get high priority causing a deadlock
[
https://issues.apache.org/jira/browse/HBASE-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172916#comment-15172916
]
Hadoop QA commented on HBASE-15295:
---
| (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: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 19 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 11s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
44s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 55s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 52s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 9s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 9s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 58s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-client
(total was 532, now 466). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 2s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 58s
{color} | {color:green} hbase-client in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 14s
{color} | {color:green} hbase-it in the patch passed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 68m 0s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 28s
{color} | {color:green} hbase-client in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 33s
{color} | {color:green} hbase-it in the patch passed with JDK v1.7.0_95.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 108m 46s
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
59s {color} |
[jira] [Commented] (HBASE-14801) Enhance the Spark-HBase connector catalog with json format
[ https://issues.apache.org/jira/browse/HBASE-14801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172909#comment-15172909 ] Ted Yu commented on HBASE-14801: [~jmhsieh] [~ted.m]: Mind taking a look ? Thanks > Enhance the Spark-HBase connector catalog with json format > -- > > Key: HBASE-14801 > URL: https://issues.apache.org/jira/browse/HBASE-14801 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-14801-1.patch, HBASE-14801-2.patch, > HBASE-14801-3.patch, HBASE-14801-4.patch, HBASE-14801-5.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15362) Compression Algorithm does not respect config params from hbase-site
[
https://issues.apache.org/jira/browse/HBASE-15362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172899#comment-15172899
]
Hadoop QA commented on HBASE-15362:
---
| (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: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} 5m
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 28s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 25s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m
29s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 9s
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 29s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
28s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 26s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 26s
{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.7.0_95 {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} checkstyle {color} | {color:green} 1m
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
16s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
39m 30s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 27s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 54s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 41s
{color} | {color:green} hbase-common in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
13s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 80m 58s {color}
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-29 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790583/HBASE-15362.patch |
| JIRA Issue | HBASE-15362 |
| Optional Tests | asflicense javac javadoc unit findbugs hadoopcheck
hbaseanti checkstyle compile |
| uname | Linux 7ac56c37bc52 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed
Sep 3
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172900#comment-15172900 ] Hudson commented on HBASE-15323: SUCCESS: Integrated in HBase-1.2-IT #451 (See [https://builds.apache.org/job/HBase-1.2-IT/451/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev a0301dcacf5793b865ba63f370cc44d2a2d516e0) * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15350) Enable individual unit test in hbase-spark module
[ https://issues.apache.org/jira/browse/HBASE-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172897#comment-15172897 ] Zhan Zhang commented on HBASE-15350: duplicate of HBASE-14167 > Enable individual unit test in hbase-spark module > - > > Key: HBASE-15350 > URL: https://issues.apache.org/jira/browse/HBASE-15350 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-15350-1.patch, HBASE-15350-2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15350) Enable individual unit test in hbase-spark module
[ https://issues.apache.org/jira/browse/HBASE-15350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhan Zhang updated HBASE-15350: --- Status: Open (was: Patch Available) > Enable individual unit test in hbase-spark module > - > > Key: HBASE-15350 > URL: https://issues.apache.org/jira/browse/HBASE-15350 > Project: HBase > Issue Type: Sub-task >Reporter: Zhan Zhang >Assignee: Zhan Zhang > Attachments: HBASE-15350-1.patch, HBASE-15350-2.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15364) Fix unescaped < characters in Javadoc
Misty Stanley-Jones created HBASE-15364:
---
Summary: Fix unescaped < characters in Javadoc
Key: HBASE-15364
URL: https://issues.apache.org/jira/browse/HBASE-15364
Project: HBase
Issue Type: Bug
Components: API, documentation
Affects Versions: 2.0.0
Reporter: Misty Stanley-Jones
>From
>https://builds.apache.org/job/HBase%20Website%20Link%20Ckecker/28/artifact/link_report/index.html:
>
{code}
host: hbase.apache.org
date: Mon, 29-Feb-2016 12:06:21 (local)
Linklint version: 2.3.5_ingo_020
#
# warn2 warnings (cross referenced)
#
unquoted "<" in <0.90.5, <0.90.5, <
occurred in
/devapidocs/org/apache/hadoop/hbase/util/HBaseFsck.html
unquoted "<" in <0.92.0) a master
res
occurred in
/devapidocs/org/apache/hadoop/hbase/util/HBaseFsck.html
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14030) HBase Backup/Restore Phase 1
[
https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172896#comment-15172896
]
Ted Yu commented on HBASE-14030:
Encountered the following test failure based on patch v36:
{code}
testBackupLogCleaner(org.apache.hadoop.hbase.backup.TestBackupLogCleaner) Time
elapsed: 82.04 sec <<< ERROR!
java.lang.IllegalArgumentException: Connection is null or closed.
at
org.apache.hadoop.hbase.backup.TestBackupLogCleaner.testBackupLogCleaner(TestBackupLogCleaner.java:89)
{code}
Investigating ...
> HBase Backup/Restore Phase 1
>
>
> Key: HBASE-14030
> URL: https://issues.apache.org/jira/browse/HBASE-14030
> Project: HBase
> Issue Type: Umbrella
>Affects Versions: 2.0.0
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
> Fix For: 2.0.0
>
> Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch,
> HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch,
> HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch,
> HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch,
> HBASE-14030-v20.patch, HBASE-14030-v21.patch, HBASE-14030-v22.patch,
> HBASE-14030-v23.patch, HBASE-14030-v24.patch, HBASE-14030-v25.patch,
> HBASE-14030-v26.patch, HBASE-14030-v27.patch, HBASE-14030-v28.patch,
> HBASE-14030-v3.patch, HBASE-14030-v30.patch, HBASE-14030-v35.patch,
> HBASE-14030-v4.patch, HBASE-14030-v5.patch, HBASE-14030-v6.patch,
> HBASE-14030-v7.patch, HBASE-14030-v8.patch, hbase-14030_v36.patch
>
>
> This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design
> doc for the phase description.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172878#comment-15172878 ] Vladimir Rodionov commented on HBASE-14030: --- Done. Thanks, [~enis] > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v21.patch, HBASE-14030-v22.patch, > HBASE-14030-v23.patch, HBASE-14030-v24.patch, HBASE-14030-v25.patch, > HBASE-14030-v26.patch, HBASE-14030-v27.patch, HBASE-14030-v28.patch, > HBASE-14030-v3.patch, HBASE-14030-v30.patch, HBASE-14030-v35.patch, > HBASE-14030-v4.patch, HBASE-14030-v5.patch, HBASE-14030-v6.patch, > HBASE-14030-v7.patch, HBASE-14030-v8.patch, hbase-14030_v36.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172874#comment-15172874 ] Ted Yu commented on HBASE-14030: Vlad: Do you mind uploading patch v36 to review board ? > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v21.patch, HBASE-14030-v22.patch, > HBASE-14030-v23.patch, HBASE-14030-v24.patch, HBASE-14030-v25.patch, > HBASE-14030-v26.patch, HBASE-14030-v27.patch, HBASE-14030-v28.patch, > HBASE-14030-v3.patch, HBASE-14030-v30.patch, HBASE-14030-v35.patch, > HBASE-14030-v4.patch, HBASE-14030-v5.patch, HBASE-14030-v6.patch, > HBASE-14030-v7.patch, HBASE-14030-v8.patch, hbase-14030_v36.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15345) add branch-1.3 post-commit builds
[ https://issues.apache.org/jira/browse/HBASE-15345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172868#comment-15172868 ] Sean Busbey commented on HBASE-15345: - Not that I know of; I thought ability to add jobs was equivalent to being able to edit all the existing jobs. IIRC, the PMC chair controls karma for jenkins. [~apurtell] can you see if there's some obvious difference in [~mantonov]'s perms? (I'm presuming we want to fix the underlying issue of spreading out access to maintaining jenkins jobs rather than the proximal need to update the config.) > add branch-1.3 post-commit builds > - > > Key: HBASE-15345 > URL: https://issues.apache.org/jira/browse/HBASE-15345 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14030) HBase Backup/Restore Phase 1
[ https://issues.apache.org/jira/browse/HBASE-14030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-14030: -- Attachment: hbase-14030_v36.patch Attaching a v36 patch which addresses some of my review comments from RB. Mainly, it is a cleanup in PB, Connection management, etc. Changes include: - proto cleanup and simplification (TableBackupStatus and BackupStatus is merged into one, BackupIdImage and ServerTimestampMap are removed, TableName change is reverted) - Move String based table args to TableName - remove indexes in PB usage - Some more cleanup elsewhere - Remove gpfs-specific exception messages - Extend AbstractHBaseTool for Driver classes so that they can be invoked with —config, etc. Clean up of some create command arguments. Some of them did not match the code. - Change a couple of RuntimeExceptions to IOExceptions. No need to throw runtime. - BackupManifest. setIncrementalTimestampMap() was not using builder at all. Why UT does not catch this? - Use jdk7 try-with-resources in most places - Remove bunch of code for “backup using existing snapshot. Won’t be supported. - Removed -silent option. Does not seem to be used. - Proper Connection management in manager / handler / backup system table > HBase Backup/Restore Phase 1 > > > Key: HBASE-14030 > URL: https://issues.apache.org/jira/browse/HBASE-14030 > Project: HBase > Issue Type: Umbrella >Affects Versions: 2.0.0 >Reporter: Vladimir Rodionov >Assignee: Vladimir Rodionov > Fix For: 2.0.0 > > Attachments: HBASE-14030-v0.patch, HBASE-14030-v1.patch, > HBASE-14030-v10.patch, HBASE-14030-v11.patch, HBASE-14030-v12.patch, > HBASE-14030-v13.patch, HBASE-14030-v14.patch, HBASE-14030-v15.patch, > HBASE-14030-v17.patch, HBASE-14030-v18.patch, HBASE-14030-v2.patch, > HBASE-14030-v20.patch, HBASE-14030-v21.patch, HBASE-14030-v22.patch, > HBASE-14030-v23.patch, HBASE-14030-v24.patch, HBASE-14030-v25.patch, > HBASE-14030-v26.patch, HBASE-14030-v27.patch, HBASE-14030-v28.patch, > HBASE-14030-v3.patch, HBASE-14030-v30.patch, HBASE-14030-v35.patch, > HBASE-14030-v4.patch, HBASE-14030-v5.patch, HBASE-14030-v6.patch, > HBASE-14030-v7.patch, HBASE-14030-v8.patch, hbase-14030_v36.patch > > > This is the umbrella ticket for Backup/Restore Phase 1. See HBASE-7912 design > doc for the phase description. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15363) Add client side metrics for SASL connection failures
Gary Helmling created HBASE-15363: - Summary: Add client side metrics for SASL connection failures Key: HBASE-15363 URL: https://issues.apache.org/jira/browse/HBASE-15363 Project: HBase Issue Type: Improvement Components: Client, metrics, security Reporter: Gary Helmling Assignee: Gary Helmling There are a number of cases where we can get SASL connection failures before getting to the server, like errors talking to the KDC/TGS and misconfiguration of kerberos principals. Hence these will not show up in the server-side authentication_failures metric. We should add client side metrics on SASL connection failures to capture these. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172831#comment-15172831 ] Hudson commented on HBASE-15323: SUCCESS: Integrated in HBase-1.3-IT #528 (See [https://builds.apache.org/job/HBase-1.3-IT/528/]) HBASE-15323 Hbase Rest CheckAndDeleteAPi should be able to delete more (enis: rev a9dd9c7b8286ec07e4ba37c467ed0bb2c6298a1b) * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/RowResource.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/RowResourceBase.java * hbase-rest/src/test/java/org/apache/hadoop/hbase/rest/TestGetAndPutResource.java * hbase-rest/src/main/java/org/apache/hadoop/hbase/rest/client/RemoteHTable.java > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15345) add branch-1.3 post-commit builds
[ https://issues.apache.org/jira/browse/HBASE-15345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172797#comment-15172797 ] Mikhail Antonov commented on HBASE-15345: - [~busbey] I guess I need to bother you again :) I'm looking at https://builds.apache.org/me/my-views/view/All/job/HBase-1.3/ job, wanted to point it to branch-1.3 instead of branch-1, and looks like I don't have permissions to update this job on ASF jenkins using my account (I can add job though). Is there a separate permission I should have to update this job? > add branch-1.3 post-commit builds > - > > Key: HBASE-15345 > URL: https://issues.apache.org/jira/browse/HBASE-15345 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172776#comment-15172776 ] Mikhail Antonov commented on HBASE-15128: - Thanks [~enis]! > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15128: -- Fix Version/s: 1.3.0 > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172772#comment-15172772 ] Enis Soztutar commented on HBASE-15128: --- Thanks. Pushed to 1.3 as well. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.3.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172770#comment-15172770 ] Mikhail Antonov commented on HBASE-15306: - opened separate issue to fix the test > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15187) Integrate CSRF prevention filter to REST gateway
[ https://issues.apache.org/jira/browse/HBASE-15187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172762#comment-15172762 ] Ted Yu commented on HBASE-15187: CSRF attack prevention is being carried out across hadoop stack (see linked JIRAs). HBase should fulfill CSRF attack prevention as well. > Integrate CSRF prevention filter to REST gateway > > > Key: HBASE-15187 > URL: https://issues.apache.org/jira/browse/HBASE-15187 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Attachments: HBASE-15187-branch-1.v13.patch, HBASE-15187.v1.patch, > HBASE-15187.v10.patch, HBASE-15187.v11.patch, HBASE-15187.v12.patch, > HBASE-15187.v13.patch, HBASE-15187.v2.patch, HBASE-15187.v3.patch, > HBASE-15187.v4.patch, HBASE-15187.v5.patch, HBASE-15187.v6.patch, > HBASE-15187.v7.patch, HBASE-15187.v8.patch, HBASE-15187.v9.patch > > > HADOOP-12691 introduced a filter in Hadoop Common to help REST APIs guard > against cross-site request forgery attacks. > This issue tracks the integration of that filter into HBase REST gateway. > From REST section of refguide: > To delete a table, use a DELETE request with the /schema endpoint: > http://example.com:8000/schema > Suppose an attacker hosts a malicious web form on a domain under his control. > The form uses the DELETE action targeting a REST URL. Through social > engineering, the attacker tricks an authenticated user into accessing the > form and submitting it. > The browser sends the HTTP DELETE request to the REST gateway. > At REST gateway, the call is executed and user table is dropped -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15362) Compression Algorithm does not respect config params from hbase-site
[ https://issues.apache.org/jira/browse/HBASE-15362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] deepankar updated HBASE-15362: -- Attachment: HBASE-15362.patch > Compression Algorithm does not respect config params from hbase-site > > > Key: HBASE-15362 > URL: https://issues.apache.org/jira/browse/HBASE-15362 > Project: HBase > Issue Type: Bug >Reporter: deepankar >Assignee: deepankar >Priority: Trivial > Attachments: HBASE-15362.patch > > > Compression creates conf using new Configuration() and this leads to it not > respecting the confs set in hbase-site, fixing it is trivial using > HBaseConfiguration.create() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15362) Compression Algorithm does not respect config params from hbase-site
[ https://issues.apache.org/jira/browse/HBASE-15362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] deepankar updated HBASE-15362: -- Status: Patch Available (was: In Progress) > Compression Algorithm does not respect config params from hbase-site > > > Key: HBASE-15362 > URL: https://issues.apache.org/jira/browse/HBASE-15362 > Project: HBase > Issue Type: Bug >Reporter: deepankar >Assignee: deepankar >Priority: Trivial > Attachments: HBASE-15362.patch > > > Compression creates conf using new Configuration() and this leads to it not > respecting the confs set in hbase-site, fixing it is trivial using > HBaseConfiguration.create() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15362) Compression Algorithm does not respect config params from hbase-site
deepankar created HBASE-15362: - Summary: Compression Algorithm does not respect config params from hbase-site Key: HBASE-15362 URL: https://issues.apache.org/jira/browse/HBASE-15362 Project: HBase Issue Type: Bug Reporter: deepankar Assignee: deepankar Priority: Trivial Compression creates conf using new Configuration() and this leads to it not respecting the confs set in hbase-site, fixing it is trivial using HBaseConfiguration.create() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (HBASE-15362) Compression Algorithm does not respect config params from hbase-site
[ https://issues.apache.org/jira/browse/HBASE-15362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15362 started by deepankar. - > Compression Algorithm does not respect config params from hbase-site > > > Key: HBASE-15362 > URL: https://issues.apache.org/jira/browse/HBASE-15362 > Project: HBase > Issue Type: Bug >Reporter: deepankar >Assignee: deepankar >Priority: Trivial > > Compression creates conf using new Configuration() and this leads to it not > respecting the confs set in hbase-site, fixing it is trivial using > HBaseConfiguration.create() -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (HBASE-15361) Remove unnecessary or Document constraints on BucketCache possible bucket sizes
deepankar created HBASE-15361:
-
Summary: Remove unnecessary or Document constraints on
BucketCache possible bucket sizes
Key: HBASE-15361
URL: https://issues.apache.org/jira/browse/HBASE-15361
Project: HBase
Issue Type: Sub-task
Components: BucketCache
Reporter: deepankar
Priority: Minor
When we were trying to tune the bucket sizes {{hbase.bucketcache.bucket.sizes}}
according to our workload, we encountered an issue due to the way offset is
stored in the bucket entry. We divide the offset into integer base and byte
value and it assumes that all bucket offsets will be a multiple of 256 (left
shifting by 8). See the code below
{code}
long offset() { // Java has no unsigned numbers
long o = ((long) offsetBase) & 0x;
o += (((long) (offset1)) & 0xFF) << 32;
return o << 8;
}
private void setOffset(long value) {
assert (value & 0xFF) == 0;
value >>= 8;
offsetBase = (int) value;
offset1 = (byte) (value >> 32);
}
{code}
This was there to save 3 bytes per BucketEntry instead of using long and when
there are no other fields in the Bucket Entry, but now there are lot of fields
in the bucket entry , This not documented so we could either document the
constraint that it should be a strict 256 bytes multiple of just go away with
this constraint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (HBASE-15361) Remove unnecessary or Document constraints on BucketCache possible bucket sizes
[
https://issues.apache.org/jira/browse/HBASE-15361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172708#comment-15172708
]
deepankar commented on HBASE-15361:
---
I can put up a patch based on the direction community suggests
> Remove unnecessary or Document constraints on BucketCache possible bucket
> sizes
>
>
> Key: HBASE-15361
> URL: https://issues.apache.org/jira/browse/HBASE-15361
> Project: HBase
> Issue Type: Sub-task
> Components: BucketCache
>Reporter: deepankar
>Priority: Minor
>
> When we were trying to tune the bucket sizes
> {{hbase.bucketcache.bucket.sizes}} according to our workload, we encountered
> an issue due to the way offset is stored in the bucket entry. We divide the
> offset into integer base and byte value and it assumes that all bucket
> offsets will be a multiple of 256 (left shifting by 8). See the code below
> {code}
> long offset() { // Java has no unsigned numbers
> long o = ((long) offsetBase) & 0x;
> o += (((long) (offset1)) & 0xFF) << 32;
> return o << 8;
> }
> private void setOffset(long value) {
> assert (value & 0xFF) == 0;
> value >>= 8;
> offsetBase = (int) value;
> offset1 = (byte) (value >> 32);
> }
> {code}
> This was there to save 3 bytes per BucketEntry instead of using long and when
> there are no other fields in the Bucket Entry, but now there are lot of
> fields in the bucket entry , This not documented so we could either document
> the constraint that it should be a strict 256 bytes multiple of just go away
> with this constraint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (HBASE-15360) Fix flaky TestSimpleRpcScheduler
Mikhail Antonov created HBASE-15360: --- Summary: Fix flaky TestSimpleRpcScheduler Key: HBASE-15360 URL: https://issues.apache.org/jira/browse/HBASE-15360 Project: HBase Issue Type: Bug Components: test Affects Versions: 2.0.0, 1.3.0 Reporter: Mikhail Antonov Assignee: Mikhail Antonov Fix For: 1.3.0 There were several flaky tests added there as part of HBASE-15306 and likely HBASE-15136. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172618#comment-15172618 ] Mikhail Antonov commented on HBASE-15306: - Haven't reproduced it locally still (also it passes more oftern on HBase-1.3 IT), but now am fairly certain it's flaky because of improper (naive) timed waits. Will fix, sorry. > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15323: -- Resolution: Fixed Fix Version/s: 1.4.0 1.1.4 1.2.1 1.3.0 2.0.0 Status: Resolved (was: Patch Available) I've pushed this to 1.1+. Thanks Ajith. > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable
[ https://issues.apache.org/jira/browse/HBASE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172557#comment-15172557 ] Ted Yu commented on HBASE-15306: You can get test output from here: https://builds.apache.org/job/HBase-Trunk_matrix/746/jdk=latest1.7,label=yahoo-not-h2/testReport/junit/org.apache.hadoop.hbase.ipc/TestSimpleRpcScheduler/testSoftAndHardQueueLimits/ > Make RPC call queue length dynamically configurable > --- > > Key: HBASE-15306 > URL: https://issues.apache.org/jira/browse/HBASE-15306 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC >Affects Versions: 1.2.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch, > HBASE-15306-v3.patch > > > Sometimes it's useful to be able to modify call queue size on prod cluster > without having to do a rolling restart. > Here setting fixed hard limit on call queue size and soft limit which is > dynamically-updatable. > https://reviews.facebook.net/D54579 for review, will test more. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15323) Hbase Rest CheckAndDeleteAPi should be able to delete more cells
[ https://issues.apache.org/jira/browse/HBASE-15323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15323: -- Release Note: Fixed an issue in REST server checkAndDelete operation where the remaining cells other than the to-be-checked column are also applied in the Delete operation. Also fixed an issue in RemoteHTable where the Delete object was not passed correctly to the REST server side. > Hbase Rest CheckAndDeleteAPi should be able to delete more cells > > > Key: HBASE-15323 > URL: https://issues.apache.org/jira/browse/HBASE-15323 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.1 > Environment: Linux And Windows >Reporter: Ajith > Attachments: HBASE-15323 Rest API CheckAndDelete4.patch > > Original Estimate: 48h > Remaining Estimate: 48h > > Java CheckAndDelete API accepts Delete object which can be used to delete (a > cell / cell version / multiple cells / column family or a row), but the rest > api only allows to delete the cell (without any version) > Need to add this capability to rest api. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172491#comment-15172491 ] Mikhail Antonov commented on HBASE-15128: - Yeah, I think we definitely want that. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172465#comment-15172465 ] Enis Soztutar commented on HBASE-15128: --- Thanks Heng. Should we push this to 1.3 branch as well. It is still early in the branch lifetime. cc [~mantonov]. > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15295) MutateTableAccess.multiMutate() does not get high priority causing a deadlock
[
https://issues.apache.org/jira/browse/HBASE-15295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-15295:
--
Attachment: hbase-15295_v4.patch
v4 fixes a test. The other failures does not seem related.
Any interest in reviewing this? It is a mostly mechanical patch.
> MutateTableAccess.multiMutate() does not get high priority causing a deadlock
> -
>
> Key: HBASE-15295
> URL: https://issues.apache.org/jira/browse/HBASE-15295
> Project: HBase
> Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: hbase-15295_v1.patch, hbase-15295_v1.patch,
> hbase-15295_v2.patch, hbase-15295_v3.patch, hbase-15295_v4.patch
>
>
> We have seen this in a cluster with Phoenix secondary indexes leading to a
> deadlock. All handlers are busy waiting on the index updates to finish:
> {code}
> "B.defaultRpcServer.handler=50,queue=0,port=16020" #91 daemon prio=5
> os_prio=0 tid=0x7f29f64ba000 nid=0xab51 waiting on condition
> [0x7f29a8762000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000124f1d5c8> (a
> com.google.common.util.concurrent.AbstractFuture$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:275)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111)
> at
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submit(BaseTaskRunner.java:66)
> at
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submitUninterruptible(BaseTaskRunner.java:99)
> at
> org.apache.phoenix.hbase.index.write.ParallelWriterIndexCommitter.write(ParallelWriterIndexCommitter.java:194)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.write(IndexWriter.java:179)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:144)
> at
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:134)
> at
> org.apache.phoenix.hbase.index.Indexer.doPostWithExceptions(Indexer.java:457)
> at org.apache.phoenix.hbase.index.Indexer.doPost(Indexer.java:406)
> at
> org.apache.phoenix.hbase.index.Indexer.postBatchMutate(Indexer.java:401)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$36.call(RegionCoprocessorHost.java:1006)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1748)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705)
> at
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postBatchMutate(RegionCoprocessorHost.java:1002)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:3162)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2801)
> at
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2743)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:692)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:654)
> at
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2031)
> at
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213)
> at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2114)
> at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:101)
> at
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
> at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> And the index region is trying to split, and is trying to do a meta update:
> {code}
> "regionserver//10.132.70.191:16020-splits-1454693389669" #1779
> prio=5 os_prio=0 tid=0x7f29e149c000 nid=0x5107 in Object.wait()
>
[jira] [Work started] (HBASE-15341) 1.3 release umbrella
[ https://issues.apache.org/jira/browse/HBASE-15341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on HBASE-15341 started by Mikhail Antonov. --- > 1.3 release umbrella > > > Key: HBASE-15341 > URL: https://issues.apache.org/jira/browse/HBASE-15341 > Project: HBase > Issue Type: Umbrella > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > > Umbrella jira for 1.3 release. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-14878) maven archetype: client application with shaded jars
[ https://issues.apache.org/jira/browse/HBASE-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172420#comment-15172420 ] Hudson commented on HBASE-14878: FAILURE: Integrated in HBase-Trunk_matrix #746 (See [https://builds.apache.org/job/HBase-Trunk_matrix/746/]) HBASE-14878 Add hbase-shaded-client archetype to hbase-archetypes (eclark: rev 83297f661b80af58190591c57d3cef1e6496e56b) * hbase-archetypes/hbase-shaded-client-project/pom.xml * hbase-archetypes/hbase-shaded-client-project/src/main/resources/log4j.properties * hbase-archetypes/hbase-shaded-client-project/src/test/java/org/apache/hbase/archetypes/exemplars/shaded_client/TestHelloHBase.java * hbase-archetypes/hbase-archetype-builder/createArchetypes.sh * hbase-archetypes/hbase-shaded-client-project/src/main/java/org/apache/hbase/archetypes/exemplars/shaded_client/package-info.java * hbase-archetypes/hbase-archetype-builder/installArchetypes.sh * hbase-archetypes/README.md * hbase-archetypes/pom.xml * hbase-archetypes/hbase-archetype-builder/pom.xml * hbase-archetypes/hbase-shaded-client-project/src/main/java/org/apache/hbase/archetypes/exemplars/shaded_client/HelloHBase.java > maven archetype: client application with shaded jars > > > Key: HBASE-14878 > URL: https://issues.apache.org/jira/browse/HBASE-14878 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14878-v1.patch, HBASE-14878-v1.patch > > > Add new archetype for generation of hbase-shaded-client dependent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15346) add 1.3 RM to docs
[ https://issues.apache.org/jira/browse/HBASE-15346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov updated HBASE-15346: Resolution: Fixed Status: Resolved (was: Patch Available) > add 1.3 RM to docs > -- > > Key: HBASE-15346 > URL: https://issues.apache.org/jira/browse/HBASE-15346 > Project: HBase > Issue Type: Sub-task > Components: documentation >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 2.0.0 > > Attachments: HBASE-15346.patch > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15343) add branch-1.3 to precommit branches
[ https://issues.apache.org/jira/browse/HBASE-15343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172413#comment-15172413 ] Sean Busbey commented on HBASE-15343: - no, post commit builds are still manually managed within the asf jenkins infrastructure. > add branch-1.3 to precommit branches > > > Key: HBASE-15343 > URL: https://issues.apache.org/jira/browse/HBASE-15343 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (HBASE-15343) add branch-1.3 to precommit branches
[ https://issues.apache.org/jira/browse/HBASE-15343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Antonov resolved HBASE-15343. - Resolution: Not A Problem > add branch-1.3 to precommit branches > > > Key: HBASE-15343 > URL: https://issues.apache.org/jira/browse/HBASE-15343 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15343) add branch-1.3 to precommit branches
[ https://issues.apache.org/jira/browse/HBASE-15343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172389#comment-15172389 ] Mikhail Antonov commented on HBASE-15343: - Ok, that's great to hear. And the same goes for post-commit builds? > add branch-1.3 to precommit branches > > > Key: HBASE-15343 > URL: https://issues.apache.org/jira/browse/HBASE-15343 > Project: HBase > Issue Type: Sub-task > Components: build >Affects Versions: 1.3.0 >Reporter: Mikhail Antonov >Assignee: Mikhail Antonov > Fix For: 1.3.0 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172375#comment-15172375 ] churro morales commented on HBASE-15321: Use case: Jobs made regionservers slow. Slow regionservers made jobs slow. Jobs took up quite a bit of regionserver resources, eg: RS heap, handlers, etc... We had jobs that did full table scans over a really large table, with lots of regions and store files. Hbase snapshots were quite slow on our large cluster (even with skip flush and manifests) they took around 20 minutes to snapshot this table. This cluster was also taking quite a bit of writes and serving random reads so the main goal being to reduce the influence these jobs had on cluster resources Hdfs snapshots are O(1) operations. Thus for our jobs, we took a snapshot in setup, ran the job over the hdfs snapshot and then deleted the snapshot after the job completed. If the job can afford to have a latency of (Now - hbase.regionserver.optionalcacheflushinterval) for your job, M/R over hdfs snapshots is a good option. This improved the speed at which the jobs completed as well as reduced the resources being consumed from hbase on our cluster. > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Fix For: 2.0.0 > > Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch, > HBASE-15321-v3.patch, HBASE-15321.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15181) A simple implementation of date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Enis Soztutar updated HBASE-15181: -- Resolution: Fixed Hadoop Flags: Reviewed Status: Resolved (was: Patch Available) Resolving this, since it seems to be committed. Thanks, Clara Xiong for the work. We would still be interested in the IO numbers, and getting some documentation for this feature if possible. > A simple implementation of date based tiered compaction > --- > > Key: HBASE-15181 > URL: https://issues.apache.org/jira/browse/HBASE-15181 > Project: HBase > Issue Type: New Feature > Components: Compaction >Reporter: Clara Xiong >Assignee: Clara Xiong > Fix For: 2.0.0, 1.3.0, 0.98.19 > > Attachments: HBASE-15181-0.98.patch, HBASE-15181-0.98.v4.patch, > HBASE-15181-98.patch, HBASE-15181-branch-1.patch, > HBASE-15181-master-v1.patch, HBASE-15181-master-v2.patch, > HBASE-15181-master-v3.patch, HBASE-15181-master-v4.patch, > HBASE-15181-v1.patch, HBASE-15181-v2.patch > > > This is a simple implementation of date-based tiered compaction similar to > Cassandra's for the following benefits: > 1. Improve date-range-based scan by structuring store files in date-based > tiered layout. > 2. Reduce compaction overhead. > 3. Improve TTL efficiency. > Perfect fit for the use cases that: > 1. has mostly date-based date write and scan and a focus on the most recent > data. > 2. never or rarely deletes data. > Out-of-order writes are handled gracefully. Time range overlapping among > store files is tolerated and the performance impact is minimized. > Configuration can be set at hbase-site.xml or overriden at per-table or > per-column-famly level by hbase shell. > Design spec is at > https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15355) region.jsp can not be found on info server of master
[ https://issues.apache.org/jira/browse/HBASE-15355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172355#comment-15172355 ] stack commented on HBASE-15355: --- [~cuijianwei] It looks like we will undo master hosting meta tables before 2.0 releases. Master hosting system tables was a stopping point while exploring master-as-regionserver. We went too far. Would it be better for you lot moving over the region.jsp or should we just fix it now so master can't host meta tables? > region.jsp can not be found on info server of master > > > Key: HBASE-15355 > URL: https://issues.apache.org/jira/browse/HBASE-15355 > Project: HBase > Issue Type: Bug > Components: UI >Affects Versions: 2.0.0 >Reporter: Jianwei Cui >Priority: Minor > > After [HBASE-10569|https://issues.apache.org/jira/browse/HBASE-10569], master > is also a regionserver and it will serve regions of system tables. The meta > region info could be viewed on master at the address such as : > http://localhost:16010/region.jsp?name=1588230740. The real path of > region.jsp for the request will be hbase-webapps/master/region.jsp on master, > however, the region.jsp is under the directory hbase-webapps/regionserver, so > that can not be found on master. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15128) Disable region splits and merges switch in master
[ https://issues.apache.org/jira/browse/HBASE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172330#comment-15172330 ] Hudson commented on HBASE-15128: SUCCESS: Integrated in HBase-1.3 #580 (See [https://builds.apache.org/job/HBase-1.3/580/]) HBASE-15128 Disable region splits and merges switch in master (chenheng: rev 18194f8a56ace9009c12decf9318f3cab26811a8) * hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/MasterRpcServices.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/Admin.java * hbase-shell/src/main/ruby/hbase/admin.rb * hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsck.java * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/ZooKeeperProtos.java * hbase-shell/src/main/ruby/shell.rb * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/SnapshotProtos.java * hbase-client/src/main/java/org/apache/hadoop/hbase/client/ConnectionManager.java * hbase-protocol/src/main/protobuf/Master.proto * hbase-protocol/src/main/protobuf/ZooKeeper.proto * hbase-shell/src/main/ruby/shell/commands/splitormerge_switch.rb * hbase-protocol/src/main/java/org/apache/hadoop/hbase/protobuf/generated/MasterProtos.java * hbase-client/src/main/java/org/apache/hadoop/hbase/zookeeper/ZooKeeperWatcher.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/AssignmentManager.java * hbase-server/src/main/java/org/apache/hadoop/hbase/zookeeper/SplitOrMergeTracker.java * hbase-shell/src/main/ruby/shell/commands/splitormerge_enabled.rb * hbase-client/src/main/java/org/apache/hadoop/hbase/protobuf/RequestConverter.java * hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestSplitOrMergeStatus.java * hbase-server/src/main/java/org/apache/hadoop/hbase/master/HMaster.java > Disable region splits and merges switch in master > - > > Key: HBASE-15128 > URL: https://issues.apache.org/jira/browse/HBASE-15128 > Project: HBase > Issue Type: Bug >Reporter: Enis Soztutar >Assignee: Heng Chen > Labels: reviewed > Fix For: 2.0.0, 1.4.0 > > Attachments: HBASE-15128-branch-1.patch, HBASE-15128.patch, > HBASE-15128_v1.patch, HBASE-15128_v3.patch, HBASE-15128_v5.patch, > HBASE-15128_v6.patch, HBASE-15128_v7.patch, HBASE-15128_v8.patch, > HBASE-15128_v9.patch > > > In large clusters where region splits are frequent, and HBCK runs take > longer, the concurrent splits cause further problems in HBCK since HBCK > assumes a static state for the region partition map. We have just seen a case > where HBCK undo's a concurrently splitting region causing number of > inconsistencies to go up. > We can have a mode in master where splits and merges are disabled like the > balancer and catalog janitor switches. Master will reject the split requests > if regionservers decide to split. This switch can be turned on / off by the > admins and also automatically by HBCK while it is running (similar to > balancer switch being disabled by HBCK). > HBCK should also disable the Catalog Janitor just in case. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15359) Simplifying Segment hierarchy
[ https://issues.apache.org/jira/browse/HBASE-15359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172329#comment-15172329 ] stack commented on HBASE-15359: --- bq. Now that it is clear that no memstore segment will be implemented as an HFIle Where does the above assertion come from [~eshcar]? Thanks for doing this cleanup if above is true. Why rollback? We don't need it anymore since HBASE-12751 and reorder of write pipeline so edit is in sync'd and in WAL before we add to memstore. Otherwise, patch looks great. > Simplifying Segment hierarchy > - > > Key: HBASE-15359 > URL: https://issues.apache.org/jira/browse/HBASE-15359 > Project: HBase > Issue Type: Sub-task >Reporter: Eshcar Hillel >Assignee: Eshcar Hillel > Fix For: 0.98.18 > > Attachments: HBASE-14918-FIX-SEGMENT.patch > > > Now that it is clear that no memstore segment will be implemented as an > HFIle, and that all segments store their data in some representation of > CellSet (skip-list or flat), the segment hierarchy can be much simplified. > The attached patch includes only 3 classes in the hierarchy: > Segment - comprises most of the state and implementation > MutableSegment - extends API with add and rollback functionality > ImmutableSegment - extends API with key-value scanner for snapshot > SegmentScanner is the scanner for all types of segments. > In addition, the option to rollback immutable segment in the memstore is > disabled. > This code would allow us to make progress independently in the compaction > subtask (HBASE-14920) and the flat index representation subtask > (HBASE-14921). It also means that the new immutable segment can reuse the > existing SegmentScanner, instead of implementing a new scanner. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15103) hadoopcheck test should provide diff file showing what's new
[ https://issues.apache.org/jira/browse/HBASE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Busbey updated HBASE-15103: Component/s: test > hadoopcheck test should provide diff file showing what's new > > > Key: HBASE-15103 > URL: https://issues.apache.org/jira/browse/HBASE-15103 > Project: HBase > Issue Type: Test > Components: test >Reporter: Ted Yu >Priority: Minor > Labels: test > > Currently developer has to go to 'build artifacts' folder to read output from > hadoopcheck test. > e.g. > https://builds.apache.org/job/PreCommit-HBASE-Build/98/artifact/patchprocess/patch-javac-2.6.1.txt > hadoopcheck test should provide diff file showing what exactly is new > Thanks to Sean for offline discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15325) ResultScanner allowing partial result will miss the rest of the row if the region is moved between two rpc requests
[
https://issues.apache.org/jira/browse/HBASE-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172241#comment-15172241
]
Hadoop QA commented on HBASE-15325:
---
| (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:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 8s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/latest/precommit-patchnames for
instructions. {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
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
55s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
42s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 5s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 13s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 22s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 17s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 7s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 7s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 6s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-client
(total was 209, now 210). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
26m 41s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 14s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 2s
{color} | {color:green} hbase-client in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 1s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 95m 0s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 21s
{color} | {color:green} hbase-client in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 16s
{color} | {color:green} hbase-common in the patch passed with
[jira] [Commented] (HBASE-15325) ResultScanner allowing partial result will miss the rest of the row if the region is moved between two rpc requests
[
https://issues.apache.org/jira/browse/HBASE-15325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172218#comment-15172218
]
Hadoop QA commented on HBASE-15325:
---
| (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:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 9s
{color} | {color:blue} The patch file was not named according to hbase's naming
conventions. Please see
https://yetus.apache.org/documentation/latest/precommit-patchnames for
instructions. {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
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 4s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 9s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
38s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 1m 55s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 12s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 16s
{color} | {color:red} hbase-client in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 17s
{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_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 21s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 2m 7s
{color} | {color:red} Patch generated 2 new checkstyle issues in hbase-client
(total was 209, now 210). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
28m 31s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m
37s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 20s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 7s
{color} | {color:green} hbase-client in the patch passed with JDK v1.8.0_72.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 4s
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72.
{color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 89m 42s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 12s
{color} | {color:green} hbase-client in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 5s
{color} | {color:green} hbase-common in the patch passed with
[jira] [Commented] (HBASE-15249) Provide lower bound on number of regions in region normalizer for pre-split tables
[ https://issues.apache.org/jira/browse/HBASE-15249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172206#comment-15172206 ] Elliott Clark commented on HBASE-15249: --- This whole normalizer seems to be running off the rails. We can't add a new config every time there's a new use case that the normalizer doesn't behave the ideal way. That leads to a feature that is so complex that everyone gets it wrong. It seems like the normalizer is currently using incorrect logic and incorrect signals. Are we sure this is a feature that will ever be complete? > Provide lower bound on number of regions in region normalizer for pre-split > tables > -- > > Key: HBASE-15249 > URL: https://issues.apache.org/jira/browse/HBASE-15249 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Labels: normalization > Attachments: HBASE-15249.v1.txt, HBASE-15249.v2.txt > > > AMS (Ambari Metrics System) developer found the following scenario: > Metrics table was pre-split with many regions on large cluster (1600 nodes). > After some time, AMS stopped working because region normalizer merged the > regions into few big regions which were not able to serve high read / write > load. > This is a big problem since the write requests flood the regions faster than > the splits can happen resulting in poor performance. > We should consider setting reasonable lower bound on region count. > If the table is pre-split, we can use initial region count as the lower bound. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15358) canEnforceTimeLimitFromScope should use timeScope instead of sizeScope
[ https://issues.apache.org/jira/browse/HBASE-15358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172184#comment-15172184 ] Hudson commented on HBASE-15358: FAILURE: Integrated in HBase-1.1-JDK7 #1672 (See [https://builds.apache.org/job/HBase-1.1-JDK7/1672/]) HBASE-15358 canEnforceTimeLimitFromScope should use timeScope instead of (zhangduo: rev 84c4fe2bd00841fe757d00759a0492a50daaa2b2) * hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/ScannerContext.java > canEnforceTimeLimitFromScope should use timeScope instead of sizeScope > -- > > Key: HBASE-15358 > URL: https://issues.apache.org/jira/browse/HBASE-15358 > Project: HBase > Issue Type: Bug > Components: Scanners >Affects Versions: 2.0.0, 1.2.0, 1.3.0, 1.1.3, 1.4.0 >Reporter: Phil Yang >Assignee: Phil Yang > Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4, 1.4.0 > > Attachments: HBASE-15358-v1.txt > > > A small but maybe critical bug -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15103) hadoopcheck test should provide diff file showing what's new
[ https://issues.apache.org/jira/browse/HBASE-15103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15103: --- Labels: test (was: ) > hadoopcheck test should provide diff file showing what's new > > > Key: HBASE-15103 > URL: https://issues.apache.org/jira/browse/HBASE-15103 > Project: HBase > Issue Type: Test >Reporter: Ted Yu >Priority: Minor > Labels: test > > Currently developer has to go to 'build artifacts' folder to read output from > hadoopcheck test. > e.g. > https://builds.apache.org/job/PreCommit-HBASE-Build/98/artifact/patchprocess/patch-javac-2.6.1.txt > hadoopcheck test should provide diff file showing what exactly is new > Thanks to Sean for offline discussion -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172180#comment-15172180 ] Anoop Sam John commented on HBASE-15321: So what is the adv of it over the MR scanner over the snapshot directly? Sorry asking to know the clear adv and use case. This will help others also. > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Fix For: 2.0.0 > > Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch, > HBASE-15321-v3.patch, HBASE-15321.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15300) Upgrade to zookeeper 3.4.8
[ https://issues.apache.org/jira/browse/HBASE-15300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15300: --- Labels: zookeeper (was: ) > Upgrade to zookeeper 3.4.8 > -- > > Key: HBASE-15300 > URL: https://issues.apache.org/jira/browse/HBASE-15300 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu >Priority: Minor > Labels: zookeeper > Attachments: HBASE-1533.v1.patch > > > zookeeper 3.4.8 has been released. > Among the fixes the following are desirable: > ZOOKEEPER-706 large numbers of watches can cause session re-establishment to > fail > ZOOKEEPER-1797 PurgeTxnLog may delete data logs during roll > This issue upgrades zookeeper dependency to 3.4.8 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15249) Provide lower bound on number of regions in region normalizer for pre-split tables
[ https://issues.apache.org/jira/browse/HBASE-15249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15249: --- Labels: normalization (was: ) > Provide lower bound on number of regions in region normalizer for pre-split > tables > -- > > Key: HBASE-15249 > URL: https://issues.apache.org/jira/browse/HBASE-15249 > Project: HBase > Issue Type: Bug >Reporter: Ted Yu >Assignee: Ted Yu > Labels: normalization > Attachments: HBASE-15249.v1.txt, HBASE-15249.v2.txt > > > AMS (Ambari Metrics System) developer found the following scenario: > Metrics table was pre-split with many regions on large cluster (1600 nodes). > After some time, AMS stopped working because region normalizer merged the > regions into few big regions which were not able to serve high read / write > load. > This is a big problem since the write requests flood the regions faster than > the splits can happen resulting in poor performance. > We should consider setting reasonable lower bound on region count. > If the table is pre-split, we can use initial region count as the lower bound. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars
[ https://issues.apache.org/jira/browse/HBASE-14878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elliott Clark updated HBASE-14878: -- Resolution: Fixed Hadoop Flags: Reviewed Fix Version/s: 2.0.0 Status: Resolved (was: Patch Available) > maven archetype: client application with shaded jars > > > Key: HBASE-14878 > URL: https://issues.apache.org/jira/browse/HBASE-14878 > Project: HBase > Issue Type: Sub-task > Components: build, Usability >Affects Versions: 2.0.0 >Reporter: Nick Dimiduk >Assignee: Daniel Vimont > Labels: beginner > Fix For: 2.0.0 > > Attachments: HBASE-14878-v1.patch, HBASE-14878-v1.patch > > > Add new archetype for generation of hbase-shaded-client dependent project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15339) Add archive tiers for date based tiered compaction
[ https://issues.apache.org/jira/browse/HBASE-15339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172173#comment-15172173 ] Dave Latham commented on HBASE-15339: - Why does MiCloud need a moving window? The idea if using different tiers is that recent windows are in the lower tier so that if recent data is "hot" then it is well partitioned and efficiently read. Other Windowing strategies do sound interesting though, please share what you come up with. > Add archive tiers for date based tiered compaction > -- > > Key: HBASE-15339 > URL: https://issues.apache.org/jira/browse/HBASE-15339 > Project: HBase > Issue Type: Improvement > Components: Compaction >Reporter: Duo Zhang > > For our MiCloud service, the old data is rarely touched but we still need to > keep it, so we want to put the data on inexpensive device and reduce > redundancy using EC to cut down the cost. > With date based tiered compaction introduced in HBASE-15181, new data and old > data can be placed in different tier. But the tier boundary moves as time > lapse so it is still possible that we do compaction on old tier which breaks > our block moving and EC work. > So here we want to introduce an "archive tier" to better fit our scenario. > Add an configuration called "archive unit", for example, year. That means, if > we find that the tier boundary is already in the previous year, then we reset > the boundary to the start of year and end of year, and if we want to do > compaction in this tier, just compact all files into one file. The file will > never be changed unless we force a major compaction so it is safe to apply EC > and other cost reducing approach on the file. And we make more tiers before > this tier year by year. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15265) Implement an asynchronous FSHLog
[
https://issues.apache.org/jira/browse/HBASE-15265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172166#comment-15172166
]
Hadoop QA commented on HBASE-15265:
---
| (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: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 14 new or modified test
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m
52s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 40s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
4s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 0s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
48s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 36s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 11s
{color} | {color:red} Patch generated 23 new checkstyle issues in hbase-server
(total was 114, now 111). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
24m 31s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 1s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 34s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 60m 7s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 58m 23s {color}
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
24s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 165m 14s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Timed out junit tests |
org.apache.hadoop.hbase.master.procedure.TestServerCrashProcedure |
| | org.apache.hadoop.hbase.master.procedure.TestEnableTableProcedure |
| | org.apache.hadoop.hbase.coprocessor.TestHTableWrapper |
| | org.apache.hadoop.hbase.mapreduce.TestTableInputFormat |
| | org.apache.hadoop.hbase.client.TestMultipleTimestamps |
| | org.apache.hadoop.hbase.master.TestGetLastFlushedSequenceId |
| |
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172162#comment-15172162 ] churro morales commented on HBASE-15321: Yes it is used on the client side, not by the regoinserver at all for the use case we had. > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Fix For: 2.0.0 > > Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch, > HBASE-15321-v3.patch, HBASE-15321.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172154#comment-15172154 ] Anoop Sam John commented on HBASE-15321: Sorry did not get what I was asking. How it is used in cluster? How you will open the HRegion? Opened at client end? > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Fix For: 2.0.0 > > Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch, > HBASE-15321-v3.patch, HBASE-15321.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT
[ https://issues.apache.org/jira/browse/HBASE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-15243: --- Description: As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek value. This would save unnecessary accesses to blocks which are not in scan result. was:As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek value. > Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList > return SEEK_NEXT_USING_HINT > -- > > Key: HBASE-15243 > URL: https://issues.apache.org/jira/browse/HBASE-15243 > Project: HBase > Issue Type: Improvement >Reporter: Ted Yu >Assignee: Ted Yu > Fix For: 2.0.0, 1.3.0 > > Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, > HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt, > HBASE-15243-v6.txt, HBASE-15243-v7.txt > > > As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters > in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should > return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek > value. > This would save unnecessary accesses to blocks which are not in scan result. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15322) HBase 1.1.3 crashing
[ https://issues.apache.org/jira/browse/HBASE-15322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172100#comment-15172100 ] Nick Dimiduk commented on HBASE-15322: -- bq. Started with one jira ticket and many following Jiras added to that... Okay. Please mark all of these tickets as 1.1.4. Thanks. > HBase 1.1.3 crashing > > > Key: HBASE-15322 > URL: https://issues.apache.org/jira/browse/HBASE-15322 > Project: HBase > Issue Type: Bug > Components: hbase >Affects Versions: 1.1.3 > Environment: OS: Ubuntu 14.04/Ubuntu 15.10 > JDK: OpenJDK8/OpenJDK9 >Reporter: Anant Sharma >Priority: Critical > Fix For: 1.1.4 > > > HBase crashes in standalone mode with the following log: > __ > 2016-02-24 22:38:37,578 ERROR [main] master.HMasterCommandLine: Master exiting > java.lang.RuntimeException: Failed construction of Master: class > org.apache.hadoop.hbase.master.HMaster > at > org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:2341) > at > org.apache.hadoop.hbase.master.HMasterCommandLine.startMaster(HMasterCommandLine.java:233) > at > org.apache.hadoop.hbase.master.HMasterCommandLine.run(HMasterCommandLine.java:139) > at org.apache.hadoop.util.ToolRunner.run(ToolRunner.java:70) > at > org.apache.hadoop.hbase.util.ServerCommandLine.doMain(ServerCommandLine.java:126) > at org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:2355) > Caused by: java.lang.NoClassDefFoundError: Could not initialize class > org.apache.hadoop.hbase.util.Bytes$LexicographicalComparerHolder$UnsafeComparer > at org.apache.hadoop.hbase.util.Bytes.putInt(Bytes.java:899) > at > org.apache.hadoop.hbase.KeyValue.createByteArray(KeyValue.java:1082) > at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:652) > at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:580) > at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:483) > at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:370) > at org.apache.hadoop.hbase.KeyValue.(KeyValue.java:267) > at org.apache.hadoop.hbase.HConstants.(HConstants.java:978) > at > org.apache.hadoop.hbase.HTableDescriptor.(HTableDescriptor.java:1488) > at > org.apache.hadoop.hbase.util.FSTableDescriptors.(FSTableDescriptors.java:124) > at > org.apache.hadoop.hbase.regionserver.HRegionServer.(HRegionServer.java:570) > at org.apache.hadoop.hbase.master.HMaster.(HMaster.java:365) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > at > org.apache.hadoop.hbase.master.HMaster.constructMaster(HMaster.java:2336) > __ > The class is in the hbase-common.jar and its there in the classpath as can be > seen from the log: > _ > 2016-02-24 22:38:32,538 INFO [main] util.ServerCommandLine: >
[jira] [Commented] (HBASE-15321) Ability to open a HRegion from hdfs snapshot.
[ https://issues.apache.org/jira/browse/HBASE-15321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172096#comment-15172096 ] churro morales commented on HBASE-15321: [~anoop.hbase] This is different from HBASE-8369. If you want to open a HRegion over a hdfs snapshot you can not do anything but a read operation. So when you initialize a HRegion currently you could possibly clean up the temp directory, clean up splits, or replay logs - all of these would fail when attempted over a hdfs snapshot. > Ability to open a HRegion from hdfs snapshot. > - > > Key: HBASE-15321 > URL: https://issues.apache.org/jira/browse/HBASE-15321 > Project: HBase > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: churro morales > Fix For: 2.0.0 > > Attachments: HBASE-15321-v1.patch, HBASE-15321-v2.patch, > HBASE-15321-v3.patch, HBASE-15321.patch > > > Now that hdfs snapshots are here, we started to run our mapreduce jobs over > hdfs snapshots. The thing is, hdfs snapshots are read-only point-in-time > copies of the file system. Thus we had to modify the section of code that > initialized the region internals in HRegion. We have to skip cleanup of > certain directories if the HRegion is backed by a hdfs snapshot. I have a > patch for trunk with some basic tests if folks are interested. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (HBASE-15359) Simplifying Segment hierarchy
[
https://issues.apache.org/jira/browse/HBASE-15359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15172086#comment-15172086
]
Hadoop QA commented on HBASE-15359:
---
| (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: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 39s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m
24s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
18s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 4s
{color} | {color:red} hbase-server in master has 1 extant Findbugs warnings.
{color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 37s
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 21s
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server
(total was 2, now 3). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}
25m 54s {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.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 5s
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 31s
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 19m 1s {color}
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 99m 49s
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95.
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m
15s {color} | {color:green} Patch does not generate ASF License warnings.
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 168m 40s {color}
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests | hadoop.hbase.ipc.TestSimpleRpcScheduler |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-29 |
| JIRA Patch URL |
https://issues.apache.org/jira/secure/attachment/12790473/HBASE-14918-FIX-SEGMENT.patch
|
| JIRA Issue | HBASE-15359
