[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator

2017-04-21 Thread Vikas Vishwakarma (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979765#comment-15979765
 ] 

Vikas Vishwakarma commented on HBASE-17877:
---

[~adongre] I basically used guava UnsignedBytesBenchmark based implementation 
for the benchmarks running them against different comparator implementations , 
different byte array sizes, etc .. only difference is to use randomized byte 
array inputs instead of changing just the last byte else the results are 
impacted by compiler optimizations
https://github.com/google/guava/blob/master/guava-tests/benchmark/com/google/common/primitives/UnsignedBytesBenchmark.java

> Replace/improve HBase's byte[] comparator
> -
>
> Key: HBASE-17877
> URL: https://issues.apache.org/jira/browse/HBASE-17877
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Vikas Vishwakarma
> Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, 
> 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, 
> HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, 
> HBASE-17877.master.001.patch, HBASE-17877.master.002.patch
>
>
> [~vik.karma] did some extensive tests and found that Hadoop's version is 
> faster - dramatically faster in some cases.
> Patch forthcoming.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17448) Export metrics from RecoverableZooKeeper

2017-04-21 Thread Chinmay Kulkarni (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chinmay Kulkarni updated HBASE-17448:
-
Attachment: HBASE-17448.patch

Corrected patch to work for master.

> Export metrics from RecoverableZooKeeper
> 
>
> Key: HBASE-17448
> URL: https://issues.apache.org/jira/browse/HBASE-17448
> Project: HBase
>  Issue Type: Improvement
>  Components: Zookeeper
>Affects Versions: 1.3.1
>Reporter: Andrew Purtell
>Assignee: Chinmay Kulkarni
>  Labels: patch
> Fix For: 1.3.2
>
> Attachments: HBASE-17448.patch
>
>
> Consider adding instrumentation to RecoverableZooKeeper that exposes metrics 
> on the performance and health of the embedded ZooKeeper client: latency 
> histograms for each op type, number of reconnections, number of ops where a 
> reconnection was necessary to proceed, number of failed ops due to 
> CONNECTIONLOSS, number of failed ops due to SESSIONEXIPRED, number of failed 
> ops due to OPERATIONTIMEOUT. 
> RecoverableZooKeeper is a class in hbase-client so we can hook up the new 
> metrics to both client- and server-side metrics reporters. Probably this 
> metrics source should be a process singleton. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17448) Export metrics from RecoverableZooKeeper

2017-04-21 Thread Chinmay Kulkarni (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chinmay Kulkarni updated HBASE-17448:
-
Attachment: HBASE-17448.patch

> Export metrics from RecoverableZooKeeper
> 
>
> Key: HBASE-17448
> URL: https://issues.apache.org/jira/browse/HBASE-17448
> Project: HBase
>  Issue Type: Improvement
>  Components: Zookeeper
>Affects Versions: 1.3.1
>Reporter: Andrew Purtell
>Assignee: Chinmay Kulkarni
>  Labels: patch
> Fix For: 1.3.2
>
> Attachments: HBASE-17448.patch
>
>
> Consider adding instrumentation to RecoverableZooKeeper that exposes metrics 
> on the performance and health of the embedded ZooKeeper client: latency 
> histograms for each op type, number of reconnections, number of ops where a 
> reconnection was necessary to proceed, number of failed ops due to 
> CONNECTIONLOSS, number of failed ops due to SESSIONEXIPRED, number of failed 
> ops due to OPERATIONTIMEOUT. 
> RecoverableZooKeeper is a class in hbase-client so we can hook up the new 
> metrics to both client- and server-side metrics reporters. Probably this 
> metrics source should be a process singleton. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17448) Export metrics from RecoverableZooKeeper

2017-04-21 Thread Chinmay Kulkarni (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chinmay Kulkarni updated HBASE-17448:
-
Attachment: (was: HBASE-17448.patch)

> Export metrics from RecoverableZooKeeper
> 
>
> Key: HBASE-17448
> URL: https://issues.apache.org/jira/browse/HBASE-17448
> Project: HBase
>  Issue Type: Improvement
>  Components: Zookeeper
>Affects Versions: 1.3.1
>Reporter: Andrew Purtell
>Assignee: Chinmay Kulkarni
>  Labels: patch
> Fix For: 1.3.2
>
> Attachments: HBASE-17448.patch
>
>
> Consider adding instrumentation to RecoverableZooKeeper that exposes metrics 
> on the performance and health of the embedded ZooKeeper client: latency 
> histograms for each op type, number of reconnections, number of ops where a 
> reconnection was necessary to proceed, number of failed ops due to 
> CONNECTIONLOSS, number of failed ops due to SESSIONEXIPRED, number of failed 
> ops due to OPERATIONTIMEOUT. 
> RecoverableZooKeeper is a class in hbase-client so we can hook up the new 
> metrics to both client- and server-side metrics reporters. Probably this 
> metrics source should be a process singleton. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17448) Export metrics from RecoverableZooKeeper

2017-04-21 Thread Chinmay Kulkarni (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chinmay Kulkarni updated HBASE-17448:
-
Attachment: (was: HBASE-17448.patch)

> Export metrics from RecoverableZooKeeper
> 
>
> Key: HBASE-17448
> URL: https://issues.apache.org/jira/browse/HBASE-17448
> Project: HBase
>  Issue Type: Improvement
>  Components: Zookeeper
>Affects Versions: 1.3.1
>Reporter: Andrew Purtell
>Assignee: Chinmay Kulkarni
>  Labels: patch
> Fix For: 1.3.2
>
> Attachments: HBASE-17448.patch
>
>
> Consider adding instrumentation to RecoverableZooKeeper that exposes metrics 
> on the performance and health of the embedded ZooKeeper client: latency 
> histograms for each op type, number of reconnections, number of ops where a 
> reconnection was necessary to proceed, number of failed ops due to 
> CONNECTIONLOSS, number of failed ops due to SESSIONEXIPRED, number of failed 
> ops due to OPERATIONTIMEOUT. 
> RecoverableZooKeeper is a class in hbase-client so we can hook up the new 
> metrics to both client- and server-side metrics reporters. Probably this 
> metrics source should be a process singleton. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Yi Liang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-17933:
-
Attachment: HBase-17933-V4.patch

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch, 
> HBase-17933-V3.patch, HBase-17933-V4.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Yi Liang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979670#comment-15979670
 ] 

Yi Liang commented on HBASE-17933:
--

Can only fix a few warnings. some warnings happen when {quote}import 
org.apache.hadoop.hbase.spark.*{quote},  since in hbase-spark, the javadoc of 
scala code are not generated. 

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch, 
> HBase-17933-V3.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-15320) HBase connector for Kafka Connect

2017-04-21 Thread Jean-Marc Spaggiari (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979638#comment-15979638
 ] 

Jean-Marc Spaggiari commented on HBASE-15320:
-

@stack can you please get this JIRA assigned to Mike?
Thanks.

> HBase connector for Kafka Connect
> -
>
> Key: HBASE-15320
> URL: https://issues.apache.org/jira/browse/HBASE-15320
> Project: HBase
>  Issue Type: New Feature
>  Components: Replication
>Reporter: Andrew Purtell
>  Labels: beginner
> Fix For: 2.0.0
>
>
> Implement an HBase connector with source and sink tasks for the Connect 
> framework (http://docs.confluent.io/2.0.0/connect/index.html) available in 
> Kafka 0.9 and later.
> See also: 
> http://www.confluent.io/blog/announcing-kafka-connect-building-large-scale-low-latency-data-pipelines
> An HBase source 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#task-example-source-task)
>  could be implemented as a replication endpoint or WALObserver, publishing 
> cluster wide change streams from the WAL to one or more topics, with 
> configurable mapping and partitioning of table changes to topics.  
> An HBase sink task 
> (http://docs.confluent.io/2.0.0/connect/devguide.html#sink-tasks) would 
> persist, with optional transformation (JSON? Avro?, map fields to native 
> schema?), Kafka SinkRecords into HBase tables.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979609#comment-15979609
 ] 

Ted Yu commented on HBASE-17947:


+1

> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (HBASE-17400) TestHRegion#testWritesWhileScanning occasionally hangs in MVCC#.waitForRead()

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu resolved HBASE-17400.

Resolution: Cannot Reproduce

> TestHRegion#testWritesWhileScanning occasionally hangs in MVCC#.waitForRead()
> -
>
> Key: HBASE-17400
> URL: https://issues.apache.org/jira/browse/HBASE-17400
> Project: HBase
>  Issue Type: Bug
>Reporter: Ted Yu
> Attachments: testHRegion-0e4866.out, 
> testHRegionWithInMemoryFlush-0e4866.out, 
> testHRegionWithInMemoryFlush-output.0123
>
>
> Looping TestHRegionWithInMemoryFlush with commit 
> 0e48665641b16cd9b250503696b926a568063654 , I got the following error at 
> iteration #33:
> {code}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 600.163 sec 
> <<< FAILURE! - in 
> org.apache.hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush
> org.apache.hadoop.hbase.regionserver.TestHRegionWithInMemoryFlush  Time 
> elapsed: 600.019 sec  <<< ERROR!
> org.junit.runners.model.TestTimedOutException: test timed out after 10 minutes
>   at java.lang.Object.wait(Native Method)
>   at 
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.waitForRead(MultiVersionConcurrencyControl.java:218)
>   at 
> org.apache.hadoop.hbase.regionserver.MultiVersionConcurrencyControl.completeAndWait(MultiVersionConcurrencyControl.java:149)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.getNextSequenceId(HRegion.java:2731)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.internalPrepareFlushCache(HRegion.java:2446)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2342)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2313)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.internalFlushcache(HRegion.java:2303)
>   at org.apache.hadoop.hbase.regionserver.HRegion.doClose(HRegion.java:1600)
>   at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1505)
>   at org.apache.hadoop.hbase.regionserver.HRegion.close(HRegion.java:1455)
>   at 
> org.apache.hadoop.hbase.HBaseTestingUtility.closeRegionAndWAL(HBaseTestingUtility.java:374)
>   at 
> org.apache.hadoop.hbase.regionserver.TestHRegion.testWritesWhileScanning(TestHRegion.java:3985)
> {code}
> See attached test output for details.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17860) Implement secure native client connection

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17860:
---
Labels: native  (was: )

> Implement secure native client connection
> -
>
> Key: HBASE-17860
> URL: https://issues.apache.org/jira/browse/HBASE-17860
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Ted Yu
>Assignee: Ted Yu
>Priority: Critical
>  Labels: native
> Attachments: 17860.v21.txt, 17860.v2.txt, 17860.v3.txt, 17860.v4.txt
>
>
> So far, the native client communicates with insecure cluster.
> This JIRA is to add secure connection support for native client using Cyrus 
> library.
> The work is based on earlier implementation and is redone via wangle and 
> folly frameworks.
> Thanks to [~devaraj] who started the initiative.
> Here is high level description of the design:
> * SaslHandler is declared as:
> {code}
> class SaslHandler
> : public wangle::HandlerAdapter std::unique_ptr>{
> {code}
> It would be inserted between EventBaseHandler and 
> LengthFieldBasedFrameDecoder in the pipeline (via 
> RpcPipelineFactory::newPipeline())
> * SaslHandler would intercept writes to server by buffering the IOBuf's and 
> start the handshake process (via sasl_client_XX calls provided by Cyrus)
> * after handshake is complete, SaslHandler would send the buffered IOBuf's to 
> server and act as pass-thru from then on



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16314) Retry on table snapshot failure during full backup

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-16314:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Thanks for the patch, Vlad.

> Retry on table snapshot failure during full backup
> --
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, 
> HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, 
> HBASE-16314-v6.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException 
> (splits, AM region moves). We need to add retry logic here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16314) Retry on table snapshot failure during full backup

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-16314:
---
Summary: Retry on table snapshot failure during full backup  (was: Retry on 
table snapshot failure)

> Retry on table snapshot failure during full backup
> --
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, 
> HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, 
> HBASE-16314-v6.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException 
> (splits, AM region moves). We need to add retry logic here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16314) Retry on table snapshot failure

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979540#comment-15979540
 ] 

Hadoop QA commented on HBASE-16314:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 41s 
{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} 7m 
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 41s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
35s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 6s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
27s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 18s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 18s 
{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 
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
57m 27s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 111m 26s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
51s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 199m 6s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestPerColumnFamilyFlush |
| Timed out junit tests | 
org.apache.hadoop.hbase.security.visibility.TestVisibilityLabelsWithDeletes |
|   | org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd |
|   | org.apache.hadoop.hbase.mapred.TestTableSnapshotInputFormat |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864552/HBASE-16314-v6.patch |
| JIRA Issue | HBASE-16314 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux d2a820f92e05 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / a3b6f4a |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6532/artifact/patchprocess/patch-unit-hbase-server.txt
 |
| unit test logs |  
https://builds.apache.org/job/PreCommit-HBASE-Build/6532/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6532/testReport/ |
| modules | C: 

[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979386#comment-15979386
 ] 

Ted Yu commented on HBASE-17943:


Let's try the new thresholds.

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Chia-Ping Tsai (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979352#comment-15979352
 ] 

Chia-Ping Tsai commented on HBASE-17943:


bq. How are the new thresholds determined ?
The ut put the fixed-size data to test the in-memory compaction, hence i adjust 
the threshold to be greater than the size of test data with the aim of 
preventing extra compaction happen.

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-14167) hbase-spark integration tests do not respect -DskipIntegrationTests

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-14167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-14167:

Fix Version/s: (was: 2.0.0)

> hbase-spark integration tests do not respect -DskipIntegrationTests
> ---
>
> Key: HBASE-14167
> URL: https://issues.apache.org/jira/browse/HBASE-14167
> Project: HBase
>  Issue Type: Improvement
>  Components: pom, spark
>Affects Versions: 2.0.0
>Reporter: Andrew Purtell
>Priority: Minor
> Attachments: HBASE-14167.11.patch, HBASE-14167-master-v2.patch
>
>
> When running a build with {{mvn ... -DskipIntegrationTests}}, the hbase-spark 
> module's integration tests do not respect the flag and run anyway. Fix. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979332#comment-15979332
 ] 

Sean Busbey commented on HBASE-17933:
-

are the javadoc warnings fixable?

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch, 
> HBase-17933-V3.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979325#comment-15979325
 ] 

Hadoop QA commented on HBASE-17933:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 27s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
1s {color} | {color:green} The patch appears to include 1 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
16s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 10s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m 
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
58s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} scalac {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
11s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 28s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
42s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javadoc {color} | {color:red} 0m 12s 
{color} | {color:red} hbase-spark generated 8 new + 18 unchanged - 0 fixed = 26 
total (was 18) {color} |
| {color:green}+1{color} | {color:green} scaladoc {color} | {color:green} 0m 
21s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 17s 
{color} | {color:green} hbase-spark in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
19s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 42m 10s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864547/HBase-17933-V3.patch |
| JIRA Issue | HBASE-17933 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  scalac  scaladoc  |
| uname | Linux dbc00496da51 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 
13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / a3b6f4a |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| javadoc | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6533/artifact/patchprocess/diff-javadoc-javadoc-hbase-spark.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6533/testReport/ |
| modules | C: hbase-spark U: hbase-spark |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6533/console |
| Powered by | 

[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979319#comment-15979319
 ] 

Ted Yu commented on HBASE-17943:


How are the new thresholds determined ?

Thanks

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979309#comment-15979309
 ] 

Hudson commented on HBASE-17944:


ABORTED: Integrated in Jenkins build HBase-1.2-JDK8 #121 (See 
[https://builds.apache.org/job/HBase-1.2-JDK8/121/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
5efecdde9ae68ca8c99012b177b817111a0bf7fc)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979310#comment-15979310
 ] 

Hudson commented on HBASE-17944:


ABORTED: Integrated in Jenkins build HBase-1.2-JDK7 #125 (See 
[https://builds.apache.org/job/HBase-1.2-JDK7/125/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
5efecdde9ae68ca8c99012b177b817111a0bf7fc)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Chia-Ping Tsai (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979307#comment-15979307
 ] 

Chia-Ping Tsai commented on HBASE-17943:


[~yuzhih...@gmail.com] Any comment? Thanks

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979305#comment-15979305
 ] 

Hudson commented on HBASE-17944:


ABORTED: Integrated in Jenkins build HBase-1.3-JDK7 #149 (See 
[https://builds.apache.org/job/HBase-1.3-JDK7/149/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
26d278818709613a7e9cd27bca7857c6383f9677)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979292#comment-15979292
 ] 

Hadoop QA commented on HBASE-17943:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 31s 
{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} 6m 
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
27s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
25s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 51s 
{color} | {color:green} master passed {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 20s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 20s 
{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 
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
56m 14s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 
50s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 111m 9s {color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m 
1s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 194m 10s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Timed out junit tests | 
org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
|   | org.apache.hadoop.hbase.snapshot.TestMobExportSnapshot |
|   | org.apache.hadoop.hbase.snapshot.TestMobRestoreFlushSnapshotFromClient |
|   | org.apache.hadoop.hbase.snapshot.TestFlushSnapshotFromClient |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864533/HBASE-17943.addendum.patch
 |
| JIRA Issue | HBASE-17943 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux e3296887d473 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / a3b6f4a |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6531/artifact/patchprocess/patch-unit-hbase-server.txt
 |
| unit test logs |  
https://builds.apache.org/job/PreCommit-HBASE-Build/6531/artifact/patchprocess/patch-unit-hbase-server.txt
 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6531/testReport/ |
| modules | C: hbase-server U: hbase-server |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6531/console |
| Powered by | Apache Yetus 

[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979278#comment-15979278
 ] 

Hudson commented on HBASE-17944:


FAILURE: Integrated in Jenkins build HBase-1.4 #700 (See 
[https://builds.apache.org/job/HBase-1.4/700/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
439711e0a0b6c5a757e6853dcfc28f9716d3d0f8)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-16314) Retry on table snapshot failure

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979270#comment-15979270
 ] 

Ted Yu commented on HBASE-16314:


+1, pending QA.

> Retry on table snapshot failure
> ---
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, 
> HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, 
> HBASE-16314-v6.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException 
> (splits, AM region moves). We need to add retry logic here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-16314) Retry on table snapshot failure

2017-04-21 Thread Vladimir Rodionov (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Rodionov updated HBASE-16314:
--
Attachment: HBASE-16314-v6.patch

v6. 

> Retry on table snapshot failure
> ---
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, 
> HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, 
> HBASE-16314-v6.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException 
> (splits, AM region moves). We need to add retry logic here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-16314) Retry on table snapshot failure

2017-04-21 Thread Vladimir Rodionov (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-16314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979265#comment-15979265
 ] 

Vladimir Rodionov edited comment on HBASE-16314 at 4/21/17 7:34 PM:


Patch v6. 


was (Author: vrodionov):
v6. 

> Retry on table snapshot failure
> ---
>
> Key: HBASE-16314
> URL: https://issues.apache.org/jira/browse/HBASE-16314
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-16314-v1.patch, HBASE-16314-v2.patch, 
> HBASE-16314-v3.patch, HBASE-16314-v4.patch, HBASE-16314-v5.patch, 
> HBASE-16314-v6.patch
>
>
> Table snapshot (during full backup) can fail with NotServingRegionException 
> (splits, AM region moves). We need to add retry logic here.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979244#comment-15979244
 ] 

Hudson commented on HBASE-17944:


SUCCESS: Integrated in Jenkins build HBase-1.3-JDK8 #161 (See 
[https://builds.apache.org/job/HBase-1.3-JDK8/161/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
26d278818709613a7e9cd27bca7857c6383f9677)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Yi Liang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yi Liang updated HBASE-17933:
-
Attachment: HBase-17933-V3.patch

V3 has remove wrapper class, it now looks more clear. 

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch, 
> HBase-17933-V3.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979213#comment-15979213
 ] 

Hudson commented on HBASE-17946:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2900 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2900/])
HBASE-17946 Shell command compact_rs don't work (Guangxu Cheng) (tedyu: rev 
68e48c456dc018775df792507087bf275bf3304f)
* (edit) hbase-shell/src/main/ruby/shell/commands/compact_rs.rb


> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979214#comment-15979214
 ] 

Hudson commented on HBASE-17944:


FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #2900 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2900/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
a3b6f4addc7ec90cbebe681e75e4e60f3e6940a5)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979199#comment-15979199
 ] 

Hudson commented on HBASE-17944:


FAILURE: Integrated in Jenkins build HBase-1.2-IT #860 (See 
[https://builds.apache.org/job/HBase-1.2-IT/860/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
5efecdde9ae68ca8c99012b177b817111a0bf7fc)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979143#comment-15979143
 ] 

Hudson commented on HBASE-17944:


SUCCESS: Integrated in Jenkins build HBase-1.3-IT #29 (See 
[https://builds.apache.org/job/HBase-1.3-IT/29/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
26d278818709613a7e9cd27bca7857c6383f9677)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-15227) HBase Backup Phase 3: Fault tolerance (client/server) support

2017-04-21 Thread Vladimir Rodionov (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-15227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vladimir Rodionov updated HBASE-15227:
--
Description: 
System must be tolerant to faults: 

# Backup operations MUST be atomic (no partial completion state in the backup 
system table)
# Process must detect any type of failures which can result in a data loss 
(partial backup or partial restore) 
# Proper system table state restore and cleanup must be done in case of a 
failure
# Additional utility to repair backup system table and corresponding file 
system cleanup must be implemented

h3. Backup

h4. General FT framework implementation 

Before actual backup operation starts, snapshot of a backup system table is 
taken and system table is updated with *ACTIVE_SNAPSHOT* flag. The flag will be 
removed upon backup completion. 

In case of *any* server-side failures, client catches errors/exceptions and 
handles them:

# Cleans up backup destination (removes partial backup data)
# Cleans up any temporary data
# Deletes  any active snapshots of a tables being backed up (during full backup 
we snapshot tables)
# Restores backup system table from snapshot
# Deletes backup system table snapshot (we read snapshot name from backup 
system table before)

In case of *any* client-side failures:

Before any backup or restore operation run we check backup system table on 
*ACTIVE_SNAPSHOT*, if flag is present, operation aborts with a message that 
backup repair tool (see below) must be run

h4. Backup repair tool

The command line tool *backup repair* which executes the following steps:

# Reads info of a last failed backup session
# Cleans up backup destination (removes partial backup data)
# Cleans up any temporary data
# Deletes  any active snapshots of a tables being backed up (during full backup 
we snapshot tables)
# Restores backup system table from snapshot
# Deletes backup system table snapshot (we read snapshot name from backup 
system table before)

h4. Detection of a partial loss of data

h5. Full backup  

Export snapshot operation (?).

We count files and check sizes before and after DistCp run

h5. Incremental backup 

Conversion of WAL to HFiles, when WAL file is moved from active to archive 
directory. The code is in place to handle this situation

During DistCp run (same as above)

h3. Restore

This operation does not modify backup system table and is idempotent. No 
special FT is required.   


 
 

  was:
System must be tolerant to faults: 

# Backup operations MUST be atomic (no partial completion state in the backup 
system table)
# Process must detect any type of failures which can result in a data loss 
(partial backup or partial restore) 
# Proper system table state restore and cleanup must be done in case of a 
failure
# Additional utility to repair backup system table and corresponding file 
system cleanup must be implemented


> HBase Backup Phase 3: Fault tolerance (client/server) support
> -
>
> Key: HBASE-15227
> URL: https://issues.apache.org/jira/browse/HBASE-15227
> Project: HBase
>  Issue Type: Task
>Reporter: Vladimir Rodionov
>Assignee: Vladimir Rodionov
>Priority: Blocker
>  Labels: backup
> Fix For: 2.0.0
>
> Attachments: HBASE-15227-v3.patch, HBASE-15277-v1.patch
>
>
> System must be tolerant to faults: 
> # Backup operations MUST be atomic (no partial completion state in the backup 
> system table)
> # Process must detect any type of failures which can result in a data loss 
> (partial backup or partial restore) 
> # Proper system table state restore and cleanup must be done in case of a 
> failure
> # Additional utility to repair backup system table and corresponding file 
> system cleanup must be implemented
> h3. Backup
> h4. General FT framework implementation 
> Before actual backup operation starts, snapshot of a backup system table is 
> taken and system table is updated with *ACTIVE_SNAPSHOT* flag. The flag will 
> be removed upon backup completion. 
> In case of *any* server-side failures, client catches errors/exceptions and 
> handles them:
> # Cleans up backup destination (removes partial backup data)
> # Cleans up any temporary data
> # Deletes  any active snapshots of a tables being backed up (during full 
> backup we snapshot tables)
> # Restores backup system table from snapshot
> # Deletes backup system table snapshot (we read snapshot name from backup 
> system table before)
> In case of *any* client-side failures:
> Before any backup or restore operation run we check backup system table on 
> *ACTIVE_SNAPSHOT*, if flag is present, operation aborts with a message that 
> backup repair tool (see below) must be run
> h4. Backup repair tool
> The command line tool *backup repair* which executes the following steps:

[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Yi Liang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979119#comment-15979119
 ] 

Yi Liang commented on HBASE-17933:
--

yeah, that a good idea, thanks:),  I will try to provide a new patch using Pair 
directly. 

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17877) Replace/improve HBase's byte[] comparator

2017-04-21 Thread Avinash Dongre (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979117#comment-15979117
 ] 

Avinash Dongre commented on HBASE-17877:


Hi [~vik.karma] 
Could you please share your JMH bench-marking code ? Thanks


> Replace/improve HBase's byte[] comparator
> -
>
> Key: HBASE-17877
> URL: https://issues.apache.org/jira/browse/HBASE-17877
> Project: HBase
>  Issue Type: Bug
>Reporter: Lars Hofhansl
>Assignee: Vikas Vishwakarma
> Attachments: 17877-1.2.patch, 17877-v2-1.3.patch, 17877-v3-1.3.patch, 
> 17877-v4-1.3.patch, ByteComparatorJiraHBASE-17877.pdf, 
> HBASE-17877.branch-1.3.001.patch, HBASE-17877.branch-1.3.002.patch, 
> HBASE-17877.master.001.patch, HBASE-17877.master.002.patch
>
>
> [~vik.karma] did some extensive tests and found that Hadoop's version is 
> faster - dramatically faster in some cases.
> Patch forthcoming.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979090#comment-15979090
 ] 

Hudson commented on HBASE-17944:


SUCCESS: Integrated in Jenkins build HBase-1.1-JDK8 #1944 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1944/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
4a75661da29c7a18822d81dee7f57205277c76c1)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979085#comment-15979085
 ] 

Sean Busbey commented on HBASE-17933:
-

Why not just directly reference the Pair class in each place rather than 
introduce the new classes that extend it?

> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979081#comment-15979081
 ] 

Hudson commented on HBASE-17944:


SUCCESS: Integrated in Jenkins build HBase-1.1-JDK7 #1861 (See 
[https://builds.apache.org/job/HBase-1.1-JDK7/1861/])
HBASE-17944 - Removed unused JDK version parsing from ClassSize. (busbey: rev 
4a75661da29c7a18822d81dee7f57205277c76c1)
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/util/ClassSize.java


> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Yi Liang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15979079#comment-15979079
 ] 

Yi Liang commented on HBASE-17933:
--

Hi Sean,
   Thanks for review, yes, the annotation and comments need to be modified.
For the wrapper class, I do not quite understand what you mean using Pair 
directly, in my current implementation, all of them extends Pair class, do you 
mind explaining a little bit. 
{code}
class FamiliesQualifiersValuesKey(rowkey: ByteArrayWrapper, fqv: 
FamiliesQualifiersValues)
  extends Pair[ByteArrayWrapper, FamiliesQualifiersValues](rowkey, fqv)
class KeyFamilyQualifierValue (kfq: KeyFamilyQualifier, val value:Array[Byte])
  extends Pair[KeyFamilyQualifier, Array[Byte]](kfq, value)
{code}



> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Chia-Ping Tsai (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chia-Ping Tsai updated HBASE-17943:
---
Attachment: HBASE-17943.addendum.patch

This issue correct the threshold of in-memory flush, but it also reduce the 
value of threshold. Therefore, the test fails due to the extra flatten/merge 
caused by the lower threshold.

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Chia-Ping Tsai (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chia-Ping Tsai updated HBASE-17943:
---
Status: Patch Available  (was: Reopened)

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.addendum.patch, HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17864) Implement async snapshot/cloneSnapshot/restoreSnapshot methods

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978994#comment-15978994
 ] 

Hudson commented on HBASE-17864:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2899 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2899/])
HBASE-17864: Implement async snapshot/cloneSnapshot/restoreSnapshot (zghao: rev 
d39f40e787ecab54ee597ac4463bbbd2f5e944d9)
* (add) 
hbase-server/src/test/java/org/apache/hadoop/hbase/client/TestAsyncSnapshotAdminApi.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/HBaseAdmin.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncAdmin.java
* (edit) hbase-common/src/main/java/org/apache/hadoop/hbase/HConstants.java
* (edit) 
hbase-client/src/main/java/org/apache/hadoop/hbase/client/AsyncHBaseAdmin.java


> Implement async snapshot/cloneSnapshot/restoreSnapshot methods
> --
>
> Key: HBASE-17864
> URL: https://issues.apache.org/jira/browse/HBASE-17864
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17864.v1.patch, HBASE-17864.v2.patch, 
> HBASE-17864.v3.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17436) Add facility to provide more information for Other Regions seen on Master UI

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978957#comment-15978957
 ] 

Ted Yu commented on HBASE-17436:


Looking at MetricsRegionSourceImpl , it contains counters for region operations.
Probably we should not use MetricsRegionSource for non-counter metrics.
{code}
+  public void deleteRegionState(String encodedName) {
+if (regionStates.containsKey(encodedName)) 
regionStates.remove("encodedName");
{code}
The quoted parameter is a typo.

Where is deleteRegionState() called ?

> Add facility to provide more information for Other Regions seen on Master UI
> 
>
> Key: HBASE-17436
> URL: https://issues.apache.org/jira/browse/HBASE-17436
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Janos Gub
>  Labels: ui
> Attachments: initial.patch
>
>
> [~rpednekar] and I were looking at a case where the count displayed under 
> Other Regions was high (~1200).
> Since the table page just maintains a count instead of List of region names, 
> it is very difficult for user to determine which regions belong to this 
> category.
> We should provide facility to provide more details for this category (LOG, 
> JMX, etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17933) [hbase-spark] Support Java api for bulkload

2017-04-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978925#comment-15978925
 ] 

Sean Busbey commented on HBASE-17933:
-


Added classes still need to have {{InterfaceAudience}} annotations added.

{quote}and still keep the wrapper class{quote}

What's the advantage vs just using the Pair class directly?

{code}
295   /**
296 * A simple abstraction over the HBaseContext.bulkLoad method.
297 * Caller need to first create JavaRDD[KeyFamilyQualifierValue]
298 * It allow addition support for a user to take a JavaRDD and 
generate
299 * HFiles in stagingDir for the bulk load
{code}

This isn't true anymore, right? (the needing to create a 
{{JavaRDD[KeyFamilyQualifierValue]}})



> [hbase-spark]  Support Java api for bulkload
> 
>
> Key: HBASE-17933
> URL: https://issues.apache.org/jira/browse/HBASE-17933
> Project: HBase
>  Issue Type: New Feature
>  Components: spark
>Affects Versions: 2.0.0
>Reporter: Yi Liang
>Assignee: Yi Liang
> Fix For: 2.0.0
>
> Attachments: HBase-17933-V1.patch, HBase-17933-V2.patch
>
>
> In JavaHBaseContext, there are java api for bulkPut, bulkDelete , but no 
> Java api for bulkload. And this jira will add bulkload java api to hbase-spark



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

   Resolution: Fixed
Fix Version/s: (was: 1.1.10)
   1.1.11
   Status: Resolved  (was: Patch Available)

> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.2.6, 1.3.2, 1.1.11
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-15583) Any HTableDescriptor we give out should be immutable

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978889#comment-15978889
 ] 

Hadoop QA commented on HBASE-15583:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 28s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 10s 
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 10s 
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 21 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 24s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 6m 
1s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 8m 39s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m 
57s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 4m 
33s {color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 7m 
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m 19s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 18s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 10m 
34s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 10m 
20s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 10m 20s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m 
31s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 5m 
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
59m 36s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue} 0m 0s 
{color} | {color:blue} Skipped patched modules with no Java source: . {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 8m 
53s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 6m 20s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 3m 16s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 187m 16s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 54s 
{color} | {color:green} hbase-rsgroup in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 5m 25s 
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m 24s 
{color} | {color:green} hbase-rest in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 219m 50s 
{color} | {color:red} root in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 2m 
4s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} 

[jira] [Commented] (HBASE-17263) Netty based rpc server impl

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978836#comment-15978836
 ] 

Hadoop QA commented on HBASE-17263:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 36s 
{color} | {color:blue} Docker mode activated. {color} |
| {color: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 6 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 7m 
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 38s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
36s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 8s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 18s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 
44s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
38s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
64m 55s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 
26s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 174m 53s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 1m 
15s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 271m 44s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.regionserver.TestRegionReplicaFailover |
|   | hadoop.hbase.snapshot.TestSecureExportSnapshot |
|   | hadoop.hbase.snapshot.TestMobExportSnapshot |
|   | hadoop.hbase.regionserver.TestPerColumnFamilyFlush |
|   | hadoop.hbase.security.access.TestCoprocessorWhitelistMasterObserver |
|   | hadoop.hbase.regionserver.TestCorruptedRegionStoreFile |
| Timed out junit tests | 
org.apache.hadoop.hbase.replication.regionserver.TestWALEntryStream |
|   | org.apache.hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
|   | org.apache.hadoop.hbase.TestIOFencing |
|   | org.apache.hadoop.hbase.client.TestCloneSnapshotFromClient |
|   | org.apache.hadoop.hbase.filter.TestFuzzyRowFilterEndToEnd |
|   | org.apache.hadoop.hbase.TestPartialResultsFromClientSide |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12851593/HBASE-17263_v8.patch |
| JIRA Issue | HBASE-17263 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 521c6fbaa19f 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / 33dadc1 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
| unit | 

[jira] [Commented] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978817#comment-15978817
 ] 

Hadoop QA commented on HBASE-17125:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 37s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 5 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 27s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
37s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 33s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m 
42s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
34s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 15s 
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 32s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m 
43s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
34s {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} 
33m 29s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m 
18s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m 
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 31s 
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 28s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 121m 53s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
51s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 208m 56s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.snapshot.TestMobExportSnapshot |
|   | hadoop.hbase.snapshot.TestExportSnapshot |
|   | hadoop.hbase.snapshot.TestMobSecureExportSnapshot |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864479/HBASE-17125.master.009.patch
 |
| JIRA Issue | HBASE-17125 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  cc  hbaseprotoc  |
| uname | Linux 

[jira] [Updated] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

Fix Version/s: 1.4.0

> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.4.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17514) Warn when Thrift Server 1 is configured for proxy users but not the HTTP transport

2017-04-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978810#comment-15978810
 ] 

Sean Busbey commented on HBASE-17514:
-

all yours!

> Warn when Thrift Server 1 is configured for proxy users but not the HTTP 
> transport
> --
>
> Key: HBASE-17514
> URL: https://issues.apache.org/jira/browse/HBASE-17514
> Project: HBase
>  Issue Type: Improvement
>  Components: Thrift, Usability
>Reporter: Sean Busbey
>Assignee: lv zehui
>Priority: Minor
>  Labels: beginner
>
> The config {{hbase.thrift.support.proxyuser}} is ignored if the Thrift Server 
> 1 isn't configured to use an HTTP transport with 
> {{hbase.regionserver.thrift.http}}.
> We should emit a warning if our configs request proxy user support but don't 
> specify that HTTP should be used for the transport.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (HBASE-17514) Warn when Thrift Server 1 is configured for proxy users but not the HTTP transport

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey reassigned HBASE-17514:
---

Assignee: lv zehui

> Warn when Thrift Server 1 is configured for proxy users but not the HTTP 
> transport
> --
>
> Key: HBASE-17514
> URL: https://issues.apache.org/jira/browse/HBASE-17514
> Project: HBase
>  Issue Type: Improvement
>  Components: Thrift, Usability
>Reporter: Sean Busbey
>Assignee: lv zehui
>Priority: Minor
>  Labels: beginner
>
> The config {{hbase.thrift.support.proxyuser}} is ignored if the Thrift Server 
> 1 isn't configured to use an HTTP transport with 
> {{hbase.regionserver.thrift.http}}.
> We should emit a warning if our configs request proxy user support but don't 
> specify that HTTP should be used for the transport.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Chia-Ping Tsai (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978806#comment-15978806
 ] 

Chia-Ping Tsai commented on HBASE-17125:


TestWalAndCompactingMemStoreFlush is traced by HBASE-17943.

> Inconsistent result when use filter to read data
> 
>
> Key: HBASE-17125
> URL: https://issues.apache.org/jira/browse/HBASE-17125
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: example.diff, HBASE-17125.master.001.patch, 
> HBASE-17125.master.002.patch, HBASE-17125.master.002.patch, 
> HBASE-17125.master.003.patch, HBASE-17125.master.004.patch, 
> HBASE-17125.master.005.patch, HBASE-17125.master.006.patch, 
> HBASE-17125.master.007.patch, HBASE-17125.master.008.patch, 
> HBASE-17125.master.009.patch, HBASE-17125.master.009.patch
>
>
> Assume a cloumn's max versions is 3, then we write 4 versions of this column. 
> The oldest version doesn't remove immediately. But from the user view, the 
> oldest version has gone. When user use a filter to query, if the filter skip 
> a new version, then the oldest version will be seen again. But after compact 
> the region, then the oldest version will never been seen. So it is weird for 
> user. The query will get inconsistent result before and after region 
> compaction.
> The reason is matchColumn method of UserScanQueryMatcher. It first check the 
> cell by filter, then check the number of versions needed. So if the filter 
> skip the new version, then the oldest version will be seen again when it is 
> not removed.
> Have a discussion offline with [~Apache9] and [~fenghh], now we have two 
> solution for this problem. The first idea is check the number of versions 
> first, then check the cell by filter. As the comment of setFilter, the filter 
> is called after all tests for ttl, column match, deletes and max versions 
> have been run.
> {code}
>   /**
>* Apply the specified server-side filter when performing the Query.
>* Only {@link Filter#filterKeyValue(Cell)} is called AFTER all tests
>* for ttl, column match, deletes and max versions have been run.
>* @param filter filter to run on the server
>* @return this for invocation chaining
>*/
>   public Query setFilter(Filter filter) {
> this.filter = filter;
> return this;
>   }
> {code}
> But this idea has another problem, if a column's max version is 5 and the 
> user query only need 3 versions. It first check the version's number, then 
> check the cell by filter. So the cells number of the result may less than 3. 
> But there are 2 versions which don't read anymore.
> So the second idea has three steps.
> 1. check by the max versions of this column
> 2. check the kv by filter
> 3. check the versions which user need.
> But this will lead the ScanQueryMatcher more complicated. And this will break 
> the javadoc of Query.setFilter.
> Now we don't have a final solution for this problem. Suggestions are welcomed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Sean Busbey (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978803#comment-15978803
 ] 

Sean Busbey commented on HBASE-17944:
-

+1, pushing shortly.

> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) Removed unused JDK version parsing from ClassSize.

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

Summary: Removed unused JDK version parsing from ClassSize.  (was: 
ClassSize fails with Java 9)

> Removed unused JDK version parsing from ClassSize.
> --
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

Issue Type: Improvement  (was: Bug)

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

Component/s: build

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey updated HBASE-17944:

Priority: Minor  (was: Major)

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Improvement
>  Components: build
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
>Priority: Minor
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Sean Busbey (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sean Busbey reassigned HBASE-17944:
---

Assignee: Colm O hEigeartaigh

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
>Assignee: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17946:
---
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks for the patch, Guangxu

Thanks for the review, Chiaping.

> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Reopened] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Chia-Ping Tsai (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Chia-Ping Tsai reopened HBASE-17943:


There is a test failure after I commit it.
{noformat}
testSelectiveFlushWithBasicAndMerge(org.apache.hadoop.hbase.regionserver.TestWalAndCompactingMemStoreFlush)
  Time elapsed: 0.902 sec  <<< FAILURE!
java.lang.AssertionError: expected:<13536> but was:<13472>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.hadoop.hbase.regionserver.TestWalAndCompactingMemStoreFlush.testSelectiveFlushWithBasicAndMerge(TestWalAndCompactingMemStoreFlush.java:879)
{noformat}
I will check it asap. Thanks for the reminder. [~yuzhih...@gmail.com] 

> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978724#comment-15978724
 ] 

Hadoop QA commented on HBASE-17946:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 25s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} rubocop {color} | {color:blue} 0m 0s 
{color} | {color:blue} rubocop was not available. {color} |
| {color:blue}0{color} | {color:blue} ruby-lint {color} | {color:blue} 0m 0s 
{color} | {color:blue} Ruby-lint was not available. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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 
13s {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} javadoc {color} | {color:green} 0m 12s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
14s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 46s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 8s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 43s 
{color} | {color:green} hbase-shell in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
7s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 37m 32s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864443/HBASE-17946-master-v1.patch
 |
| JIRA Issue | HBASE-17946 |
| Optional Tests |  asflicense  javac  javadoc  unit  rubocop  ruby_lint  |
| uname | Linux 22e59e085f33 3.13.0-106-generic #153-Ubuntu SMP Tue Dec 6 
15:44:32 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / d39f40e |
| Default Java | 1.8.0_121 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6530/testReport/ |
| modules | C: hbase-shell U: hbase-shell |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6530/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17436) Add facility to provide more information for Other Regions seen on Master UI

2017-04-21 Thread Janos Gub (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Janos Gub updated HBASE-17436:
--
Attachment: initial.patch

Attaching initial patch. In short I introduced metrics classes for 
RegionStates, and I update them from the AssignmentManager. In JMX each 
region's state is booked as a tag. I am not sure if it is the best way to do 
this, e.g. if the metrics are read and the AssignmentManager is deleting a 
region I think we can easily run into a ConcurrentModificationException. As an 
alternative I was thinking about somehow propagating the state to the regions 
and make this similar to the MetricsRegionAggregateSource. [~te...@apache.org] 
could you please share your thoughts?

> Add facility to provide more information for Other Regions seen on Master UI
> 
>
> Key: HBASE-17436
> URL: https://issues.apache.org/jira/browse/HBASE-17436
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Janos Gub
>  Labels: ui
> Attachments: initial.patch
>
>
> [~rpednekar] and I were looking at a case where the count displayed under 
> Other Regions was high (~1200).
> Since the table page just maintains a count instead of List of region names, 
> it is very difficult for user to determine which regions belong to this 
> category.
> We should provide facility to provide more details for this category (LOG, 
> JMX, etc).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Ted Yu (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ted Yu updated HBASE-17946:
---
Status: Patch Available  (was: Open)

> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978665#comment-15978665
 ] 

Ted Yu commented on HBASE-17946:


lgtm, pending QA.

> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17928) Shell tool to clear compact queues

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978645#comment-15978645
 ] 

Ted Yu commented on HBASE-17928:


Please cover security aspect for the new command: this command should only be 
executable by an admin.

> Shell tool to clear compact queues
> --
>
> Key: HBASE-17928
> URL: https://issues.apache.org/jira/browse/HBASE-17928
> Project: HBase
>  Issue Type: New Feature
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17928-v1.patch
>
>
> scenarioļ¼š
> 1. Compact a table by mistake
> 2. Compact is not completed within the specified time period
> In this case, clearing the queue is a better choice, so as not to affect the 
> stability of the cluster



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17928) Shell tool to clear compact queues

2017-04-21 Thread Ted Yu (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978636#comment-15978636
 ] 

Ted Yu commented on HBASE-17928:


Mind putting patch on review board ?

Java method can be named clearCompactionQueues, shell command can be named 
clear_compaction_queues.

> Shell tool to clear compact queues
> --
>
> Key: HBASE-17928
> URL: https://issues.apache.org/jira/browse/HBASE-17928
> Project: HBase
>  Issue Type: New Feature
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17928-v1.patch
>
>
> scenarioļ¼š
> 1. Compact a table by mistake
> 2. Compact is not completed within the specified time period
> In this case, clearing the queue is a better choice, so as not to affect the 
> stability of the cluster



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978609#comment-15978609
 ] 

Hadoop QA commented on HBASE-17125:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 20s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 5 new or modified test 
files. {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 29s 
{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
26s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 24s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m 
2s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {color} | {color:green} master passed {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 2m 5s 
{color} | {color:red} hbase-protocol-shaded in master has 24 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 53s 
{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue} 0m 12s 
{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 29s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} cc {color} | {color:green} 1m 29s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 29s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 11m 
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
31s {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} 
28m 38s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} hbaseprotoc {color} | {color:green} 1m 
2s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 5m 
33s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 50s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 26s 
{color} | {color:green} hbase-protocol-shaded in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 16s 
{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 112m 22s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
48s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 190m 27s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | 
hadoop.hbase.regionserver.TestWalAndCompactingMemStoreFlush |
|   | hadoop.hbase.snapshot.TestExportSnapshot |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864458/HBASE-17125.master.009.patch
 |
| JIRA Issue | HBASE-17125 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  cc  hbaseprotoc  |
| uname | Linux 2f81ad5ac9e7 3.13.0-106-generic #153-Ubuntu SMP Tue 

[jira] [Commented] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978582#comment-15978582
 ] 

Hadoop QA commented on HBASE-17947:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 17s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color: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 
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 14s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
10s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
23s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
14s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 13s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 13s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
11s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 5s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 0m 
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 11s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 17s 
{color} | {color:green} hbase-examples in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
7s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 33m 53s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.12.3 Server=1.12.3 Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864482/HBASE-17947.master.000.patch
 |
| JIRA Issue | HBASE-17947 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 49b23d241de2 3.13.0-107-generic #154-Ubuntu SMP Tue Dec 20 
09:57:27 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / d39f40e |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6529/testReport/ |
| modules | C: hbase-examples U: hbase-examples |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6529/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>   

[jira] [Commented] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978540#comment-15978540
 ] 

Xiang Li commented on HBASE-17947:
--

Easy fix, hope it could be of a little help for the new comers.

> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Fix Version/s: 2.0.0
 Tags:   (was: easy)
   Status: Patch Available  (was: Open)

> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
> Fix For: 2.0.0
>
> Attachments: HBASE-17947.master.000.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Attachment: HBASE-17947.master.000.patch

> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
> Attachments: HBASE-17947.master.000.patch
>
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Description: 
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not under hbase-server/src/main/protobuf/, but under 
hbase-examples/src/main/protobuf/

  was:
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
hbase-examples/src/main/protobuf/


> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not under hbase-server/src/main/protobuf/, but under 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Location of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Summary: Location of Examples.proto is wrong in comment of 
RowCountEndPoint.java  (was: Path of Examples.proto is wrong in comment of 
RowCountEndPoint.java)

> Location of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not in hbase-server/src/main/protobuf/, but in 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Path of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Description: 
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
hbase-examples/src/main/protobuf/

  was:
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
hbase-examples/src/main/protobuf


> Path of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not in hbase-server/src/main/protobuf/, but in 
> hbase-examples/src/main/protobuf/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Path of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Tags: easy

> Path of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not in hbase-server/src/main/protobuf/, but in 
> hbase-examples/src/main/protobuf



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Path of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Labels: easyfix  (was: )

> Path of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not in hbase-server/src/main/protobuf/, but in 
> hbase-examples/src/main/protobuf



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17947) Path of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiang Li updated HBASE-17947:
-
Description: 
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
hbase-examples/src/main/protobuf

  was:
In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
/Users/water/Documents/workspace/hbase/hbase-examples/src/main/protobuf


> Path of Examples.proto is wrong in comment of RowCountEndPoint.java
> ---
>
> Key: HBASE-17947
> URL: https://issues.apache.org/jira/browse/HBASE-17947
> Project: HBase
>  Issue Type: Bug
>  Components: Coprocessors
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Trivial
>  Labels: easyfix
>
> In the comment of RowCountEndpoint.java
> {code}
> /**
>  * Sample coprocessor endpoint exposing a Service interface for counting rows 
> and key values.
>  *
>  * 
>  * For the protocol buffer definition of the RowCountService, see the source 
> file located under
>  * hbase-server/src/main/protobuf/Examples.proto.
>  * 
>  */
> {code}
> Examples.proto is not in hbase-server/src/main/protobuf/, but in 
> hbase-examples/src/main/protobuf



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (HBASE-17947) Path of Examples.proto is wrong in comment of RowCountEndPoint.java

2017-04-21 Thread Xiang Li (JIRA)
Xiang Li created HBASE-17947:


 Summary: Path of Examples.proto is wrong in comment of 
RowCountEndPoint.java
 Key: HBASE-17947
 URL: https://issues.apache.org/jira/browse/HBASE-17947
 Project: HBase
  Issue Type: Bug
  Components: Coprocessors
Reporter: Xiang Li
Assignee: Xiang Li
Priority: Trivial


In the comment of RowCountEndpoint.java
{code}
/**
 * Sample coprocessor endpoint exposing a Service interface for counting rows 
and key values.
 *
 * 
 * For the protocol buffer definition of the RowCountService, see the source 
file located under
 * hbase-server/src/main/protobuf/Examples.proto.
 * 
 */
{code}
Examples.proto is not in hbase-server/src/main/protobuf/, but in 
/Users/water/Documents/workspace/hbase/hbase-examples/src/main/protobuf



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17864) Implement async snapshot/cloneSnapshot/restoreSnapshot methods

2017-04-21 Thread Guanghao Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-17864:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Implement async snapshot/cloneSnapshot/restoreSnapshot methods
> --
>
> Key: HBASE-17864
> URL: https://issues.apache.org/jira/browse/HBASE-17864
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17864.v1.patch, HBASE-17864.v2.patch, 
> HBASE-17864.v3.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17864) Implement async snapshot/cloneSnapshot/restoreSnapshot methods

2017-04-21 Thread Guanghao Zhang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978508#comment-15978508
 ] 

Guanghao Zhang commented on HBASE-17864:


Pushed to master and thanks [~openinx] for contributing.

> Implement async snapshot/cloneSnapshot/restoreSnapshot methods
> --
>
> Key: HBASE-17864
> URL: https://issues.apache.org/jira/browse/HBASE-17864
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Zheng Hu
>Assignee: Zheng Hu
> Fix For: 2.0.0
>
> Attachments: HBASE-17864.v1.patch, HBASE-17864.v2.patch, 
> HBASE-17864.v3.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Guanghao Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-17125:
---
Attachment: HBASE-17125.master.009.patch

> Inconsistent result when use filter to read data
> 
>
> Key: HBASE-17125
> URL: https://issues.apache.org/jira/browse/HBASE-17125
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: example.diff, HBASE-17125.master.001.patch, 
> HBASE-17125.master.002.patch, HBASE-17125.master.002.patch, 
> HBASE-17125.master.003.patch, HBASE-17125.master.004.patch, 
> HBASE-17125.master.005.patch, HBASE-17125.master.006.patch, 
> HBASE-17125.master.007.patch, HBASE-17125.master.008.patch, 
> HBASE-17125.master.009.patch, HBASE-17125.master.009.patch
>
>
> Assume a cloumn's max versions is 3, then we write 4 versions of this column. 
> The oldest version doesn't remove immediately. But from the user view, the 
> oldest version has gone. When user use a filter to query, if the filter skip 
> a new version, then the oldest version will be seen again. But after compact 
> the region, then the oldest version will never been seen. So it is weird for 
> user. The query will get inconsistent result before and after region 
> compaction.
> The reason is matchColumn method of UserScanQueryMatcher. It first check the 
> cell by filter, then check the number of versions needed. So if the filter 
> skip the new version, then the oldest version will be seen again when it is 
> not removed.
> Have a discussion offline with [~Apache9] and [~fenghh], now we have two 
> solution for this problem. The first idea is check the number of versions 
> first, then check the cell by filter. As the comment of setFilter, the filter 
> is called after all tests for ttl, column match, deletes and max versions 
> have been run.
> {code}
>   /**
>* Apply the specified server-side filter when performing the Query.
>* Only {@link Filter#filterKeyValue(Cell)} is called AFTER all tests
>* for ttl, column match, deletes and max versions have been run.
>* @param filter filter to run on the server
>* @return this for invocation chaining
>*/
>   public Query setFilter(Filter filter) {
> this.filter = filter;
> return this;
>   }
> {code}
> But this idea has another problem, if a column's max version is 5 and the 
> user query only need 3 versions. It first check the version's number, then 
> check the cell by filter. So the cells number of the result may less than 3. 
> But there are 2 versions which don't read anymore.
> So the second idea has three steps.
> 1. check by the max versions of this column
> 2. check the kv by filter
> 3. check the versions which user need.
> But this will lead the ScanQueryMatcher more complicated. And this will break 
> the javadoc of Query.setFilter.
> Now we don't have a final solution for this problem. Suggestions are welcomed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Guanghao Zhang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978505#comment-15978505
 ] 

Guanghao Zhang commented on HBASE-17125:


Update the javadoc in the latest 009 patch.

> Inconsistent result when use filter to read data
> 
>
> Key: HBASE-17125
> URL: https://issues.apache.org/jira/browse/HBASE-17125
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: example.diff, HBASE-17125.master.001.patch, 
> HBASE-17125.master.002.patch, HBASE-17125.master.002.patch, 
> HBASE-17125.master.003.patch, HBASE-17125.master.004.patch, 
> HBASE-17125.master.005.patch, HBASE-17125.master.006.patch, 
> HBASE-17125.master.007.patch, HBASE-17125.master.008.patch, 
> HBASE-17125.master.009.patch, HBASE-17125.master.009.patch
>
>
> Assume a cloumn's max versions is 3, then we write 4 versions of this column. 
> The oldest version doesn't remove immediately. But from the user view, the 
> oldest version has gone. When user use a filter to query, if the filter skip 
> a new version, then the oldest version will be seen again. But after compact 
> the region, then the oldest version will never been seen. So it is weird for 
> user. The query will get inconsistent result before and after region 
> compaction.
> The reason is matchColumn method of UserScanQueryMatcher. It first check the 
> cell by filter, then check the number of versions needed. So if the filter 
> skip the new version, then the oldest version will be seen again when it is 
> not removed.
> Have a discussion offline with [~Apache9] and [~fenghh], now we have two 
> solution for this problem. The first idea is check the number of versions 
> first, then check the cell by filter. As the comment of setFilter, the filter 
> is called after all tests for ttl, column match, deletes and max versions 
> have been run.
> {code}
>   /**
>* Apply the specified server-side filter when performing the Query.
>* Only {@link Filter#filterKeyValue(Cell)} is called AFTER all tests
>* for ttl, column match, deletes and max versions have been run.
>* @param filter filter to run on the server
>* @return this for invocation chaining
>*/
>   public Query setFilter(Filter filter) {
> this.filter = filter;
> return this;
>   }
> {code}
> But this idea has another problem, if a column's max version is 5 and the 
> user query only need 3 versions. It first check the version's number, then 
> check the cell by filter. So the cells number of the result may less than 3. 
> But there are 2 versions which don't read anymore.
> So the second idea has three steps.
> 1. check by the max versions of this column
> 2. check the kv by filter
> 3. check the versions which user need.
> But this will lead the ScanQueryMatcher more complicated. And this will break 
> the javadoc of Query.setFilter.
> Now we don't have a final solution for this problem. Suggestions are welcomed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17928) Shell tool to clear compact queues

2017-04-21 Thread Guangxu Cheng (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978458#comment-15978458
 ] 

Guangxu Cheng commented on HBASE-17928:
---

[~yuzhih...@gmail.com] mind taking a look at it ? thanks

> Shell tool to clear compact queues
> --
>
> Key: HBASE-17928
> URL: https://issues.apache.org/jira/browse/HBASE-17928
> Project: HBase
>  Issue Type: New Feature
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17928-v1.patch
>
>
> scenarioļ¼š
> 1. Compact a table by mistake
> 2. Compact is not completed within the specified time period
> In this case, clearing the queue is a better choice, so as not to affect the 
> stability of the cluster



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17928) Shell tool to clear compact queues

2017-04-21 Thread Guangxu Cheng (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guangxu Cheng updated HBASE-17928:
--
Attachment: HBASE-17928-v1.patch

Add command clear_compact_queues_rs:
{code}
  hbase> clear_queues 'host187.example.com,60020'
  hbase> clear_queues 'host187.example.com,60020','long'
  hbase> clear_queues 'host187.example.com,60020', ['long','short']
{code}

> Shell tool to clear compact queues
> --
>
> Key: HBASE-17928
> URL: https://issues.apache.org/jira/browse/HBASE-17928
> Project: HBase
>  Issue Type: New Feature
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17928-v1.patch
>
>
> scenarioļ¼š
> 1. Compact a table by mistake
> 2. Compact is not completed within the specified time period
> In this case, clearing the queue is a better choice, so as not to affect the 
> stability of the cluster



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17263) Netty based rpc server impl

2017-04-21 Thread ramkrishna.s.vasudevan (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978435#comment-15978435
 ] 

ramkrishna.s.vasudevan commented on HBASE-17263:


[~aoxiang]
Sorry about putting this on hold. Totally forgot. Will check this once more 
before commit. I think if all the review comments are addressed then we are 
good to go with the commit here right?
[~anoop.hbase], [~Apache9]
Any more feedback?

>   Netty based rpc server impl
> -
>
> Key: HBASE-17263
> URL: https://issues.apache.org/jira/browse/HBASE-17263
> Project: HBase
>  Issue Type: Sub-task
>  Components: Performance, rpc
>Reporter: binlijin
>Assignee: binlijin
> Fix For: 2.0.0
>
> Attachments: HBASE-17263.patch, HBASE-17263_v2.patch, 
> HBASE-17263_v3.patch, HBASE-17263_v4.patch, HBASE-17263_v5.patch, 
> HBASE-17263_v6.patch, HBASE-17263_v7.patch, HBASE-17263_v8.patch
>
>
> An RPC server with Netty4 implementation, which provide better performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17946) Shell command compact_rs don't work

2017-04-21 Thread Chia-Ping Tsai (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978438#comment-15978438
 ] 

Chia-Ping Tsai commented on HBASE-17946:


LGTM

> Shell command compact_rs don't work
> ---
>
> Key: HBASE-17946
> URL: https://issues.apache.org/jira/browse/HBASE-17946
> Project: HBase
>  Issue Type: Bug
>  Components: shell
>Affects Versions: 2.0.0
>Reporter: Guangxu Cheng
>Assignee: Guangxu Cheng
> Fix For: 2.0.0
>
> Attachments: HBASE-17946-master-v1.patch
>
>
> error as the following:
> {code}
> hbase(main):001:0> compact_rs 'rs-host-1,16020,1492681533814'
> ERROR: undefined method `compactRegionserver' for #
>   Compact all regions on passed regionserver.
>   Examples:
>   Compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020'
>   or
>   hbase> compact_rs 'host187.example.com,60020,1289493121758'
>   Major compact all regions on a regionserver:
>   hbase> compact_rs 'host187.example.com,60020,1289493121758', true
> Took 0.0240 seconds 
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17263) Netty based rpc server impl

2017-04-21 Thread Duo Zhang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978446#comment-15978446
 ] 

Duo Zhang commented on HBASE-17263:
---

Will take a look soon.

>   Netty based rpc server impl
> -
>
> Key: HBASE-17263
> URL: https://issues.apache.org/jira/browse/HBASE-17263
> Project: HBase
>  Issue Type: Sub-task
>  Components: Performance, rpc
>Reporter: binlijin
>Assignee: binlijin
> Fix For: 2.0.0
>
> Attachments: HBASE-17263.patch, HBASE-17263_v2.patch, 
> HBASE-17263_v3.patch, HBASE-17263_v4.patch, HBASE-17263_v5.patch, 
> HBASE-17263_v6.patch, HBASE-17263_v7.patch, HBASE-17263_v8.patch
>
>
> An RPC server with Netty4 implementation, which provide better performance.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978402#comment-15978402
 ] 

Hadoop QA commented on HBASE-17944:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 27s 
{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} 6m 
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 28s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
38s {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:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 5s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 28s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
30s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 29s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 29s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 0m 
39s {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} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
65m 17s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.6.1 2.6.2 2.6.3 2.6.4 2.6.5 2.7.1 2.7.2 2.7.3 or 3.0.0-alpha2. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
49s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 40s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 4m 28s 
{color} | {color:green} hbase-common in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
17s {color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 84m 45s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.03.0-ce Server=17.03.0-ce Image:yetus/hbase:8d52d23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12864445/0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
 |
| JIRA Issue | HBASE-17944 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux b38479fe8007 4.8.3-std-1 #1 SMP Fri Oct 21 11:15:43 UTC 2016 
x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build@2/component/dev-support/hbase-personality.sh
 |
| git revision | master / 33dadc1 |
| Default Java | 1.8.0_121 |
| findbugs | v3.0.0 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6525/testReport/ |
| modules | C: hbase-common U: hbase-common |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/6525/console |
| Powered by | Apache Yetus 0.3.0   http://yetus.apache.org |


This message was automatically generated.



> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> 

[jira] [Commented] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Duo Zhang (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978373#comment-15978373
 ] 

Duo Zhang commented on HBASE-17125:
---

If not use filter, get up to the specified number of versions of each column.

If use filter, it means the maximum versions of each column will be checked by 
filter. So the scan may return less than the value you set here as the filter 
may filter out some cells. If you want to get a specific number of version for 
each column after filtering, please call setMaxVersions() and use 
SpecifiedNumVersionsColumnFilter. Notice that the 
SpecifiedNumVersionsColumnFilter should be placed at the last position in 
FilterList to make sure it will be checked at last.

Better? And seems get also has this method so you need to change the wording 
from scan to get if possible?

Thanks.

> Inconsistent result when use filter to read data
> 
>
> Key: HBASE-17125
> URL: https://issues.apache.org/jira/browse/HBASE-17125
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: example.diff, HBASE-17125.master.001.patch, 
> HBASE-17125.master.002.patch, HBASE-17125.master.002.patch, 
> HBASE-17125.master.003.patch, HBASE-17125.master.004.patch, 
> HBASE-17125.master.005.patch, HBASE-17125.master.006.patch, 
> HBASE-17125.master.007.patch, HBASE-17125.master.008.patch, 
> HBASE-17125.master.009.patch
>
>
> Assume a cloumn's max versions is 3, then we write 4 versions of this column. 
> The oldest version doesn't remove immediately. But from the user view, the 
> oldest version has gone. When user use a filter to query, if the filter skip 
> a new version, then the oldest version will be seen again. But after compact 
> the region, then the oldest version will never been seen. So it is weird for 
> user. The query will get inconsistent result before and after region 
> compaction.
> The reason is matchColumn method of UserScanQueryMatcher. It first check the 
> cell by filter, then check the number of versions needed. So if the filter 
> skip the new version, then the oldest version will be seen again when it is 
> not removed.
> Have a discussion offline with [~Apache9] and [~fenghh], now we have two 
> solution for this problem. The first idea is check the number of versions 
> first, then check the cell by filter. As the comment of setFilter, the filter 
> is called after all tests for ttl, column match, deletes and max versions 
> have been run.
> {code}
>   /**
>* Apply the specified server-side filter when performing the Query.
>* Only {@link Filter#filterKeyValue(Cell)} is called AFTER all tests
>* for ttl, column match, deletes and max versions have been run.
>* @param filter filter to run on the server
>* @return this for invocation chaining
>*/
>   public Query setFilter(Filter filter) {
> this.filter = filter;
> return this;
>   }
> {code}
> But this idea has another problem, if a column's max version is 5 and the 
> user query only need 3 versions. It first check the version's number, then 
> check the cell by filter. So the cells number of the result may less than 3. 
> But there are 2 versions which don't read anymore.
> So the second idea has three steps.
> 1. check by the max versions of this column
> 2. check the kv by filter
> 3. check the versions which user need.
> But this will lead the ScanQueryMatcher more complicated. And this will break 
> the javadoc of Query.setFilter.
> Now we don't have a final solution for this problem. Suggestions are welcomed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17125) Inconsistent result when use filter to read data

2017-04-21 Thread Guanghao Zhang (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Guanghao Zhang updated HBASE-17125:
---
Attachment: HBASE-17125.master.009.patch

Update the javadoc for setMaxVersions in 009 patch.

> Inconsistent result when use filter to read data
> 
>
> Key: HBASE-17125
> URL: https://issues.apache.org/jira/browse/HBASE-17125
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: Guanghao Zhang
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: example.diff, HBASE-17125.master.001.patch, 
> HBASE-17125.master.002.patch, HBASE-17125.master.002.patch, 
> HBASE-17125.master.003.patch, HBASE-17125.master.004.patch, 
> HBASE-17125.master.005.patch, HBASE-17125.master.006.patch, 
> HBASE-17125.master.007.patch, HBASE-17125.master.008.patch, 
> HBASE-17125.master.009.patch
>
>
> Assume a cloumn's max versions is 3, then we write 4 versions of this column. 
> The oldest version doesn't remove immediately. But from the user view, the 
> oldest version has gone. When user use a filter to query, if the filter skip 
> a new version, then the oldest version will be seen again. But after compact 
> the region, then the oldest version will never been seen. So it is weird for 
> user. The query will get inconsistent result before and after region 
> compaction.
> The reason is matchColumn method of UserScanQueryMatcher. It first check the 
> cell by filter, then check the number of versions needed. So if the filter 
> skip the new version, then the oldest version will be seen again when it is 
> not removed.
> Have a discussion offline with [~Apache9] and [~fenghh], now we have two 
> solution for this problem. The first idea is check the number of versions 
> first, then check the cell by filter. As the comment of setFilter, the filter 
> is called after all tests for ttl, column match, deletes and max versions 
> have been run.
> {code}
>   /**
>* Apply the specified server-side filter when performing the Query.
>* Only {@link Filter#filterKeyValue(Cell)} is called AFTER all tests
>* for ttl, column match, deletes and max versions have been run.
>* @param filter filter to run on the server
>* @return this for invocation chaining
>*/
>   public Query setFilter(Filter filter) {
> this.filter = filter;
> return this;
>   }
> {code}
> But this idea has another problem, if a column's max version is 5 and the 
> user query only need 3 versions. It first check the version's number, then 
> check the cell by filter. So the cells number of the result may less than 3. 
> But there are 2 versions which don't read anymore.
> So the second idea has three steps.
> 1. check by the max versions of this column
> 2. check the kv by filter
> 3. check the versions which user need.
> But this will lead the ScanQueryMatcher more complicated. And this will break 
> the javadoc of Query.setFilter.
> Now we don't have a final solution for this problem. Suggestions are welcomed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-13288) Fix naming of parameter in Delete constructor

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978291#comment-15978291
 ] 

Hudson commented on HBASE-13288:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2897 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2897/])
HBASE-13288 Fix naming of parameter in Delete constructor (chia7712: rev 
87f2bb5796bd2a05f2c9db559ddd13a33fc80e36)
* (edit) hbase-client/src/main/java/org/apache/hadoop/hbase/client/Delete.java


> Fix naming of parameter in Delete constructor
> -
>
> Key: HBASE-13288
> URL: https://issues.apache.org/jira/browse/HBASE-13288
> Project: HBase
>  Issue Type: Bug
>  Components: API
>Affects Versions: 2.0.0
>Reporter: Lars George
>Assignee: Ashish Singhi
>Priority: Trivial
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-13288.patch
>
>
> We have these two variants:
> {code}
> Delete(byte[] row, long timestamp)
> Delete(final byte[] rowArray, final int rowOffset, final int rowLength, long 
> ts)
> {code}
> Both should use {{timestamp}} as the parameter name, not this mix.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17941) CellArrayMap#getCell may throw IndexOutOfBoundsException

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978293#comment-15978293
 ] 

Hudson commented on HBASE-17941:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2897 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2897/])
HBASE-17941 CellArrayMap#getCell may throw IndexOutOfBoundsException (chia7712: 
rev 33dadc1a941a536742799a46444c67a1ed66d124)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CellArrayMap.java


> CellArrayMap#getCell may throw IndexOutOfBoundsException
> 
>
> Key: HBASE-17941
> URL: https://issues.apache.org/jira/browse/HBASE-17941
> Project: HBase
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Hsin-Ying Lee
>Priority: Minor
>  Labels: beginner
> Fix For: 2.0.0
>
> Attachments: HBASE-17941.v0.patch
>
>
> {noformat}
>   @Override
>   protected Cell getCell(int i) {
> if( (i < minCellIdx) && (i >= maxCellIdx) ) return null;
> return block[i];
>   }
> {noformat}
> && -> ||
> We have checked the index of bound before calling this method, so the 
> exception doesn't happen at current trunk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17943) The in-memory flush size is different for each CompactingMemStore located in the same region

2017-04-21 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978292#comment-15978292
 ] 

Hudson commented on HBASE-17943:


SUCCESS: Integrated in Jenkins build HBase-Trunk_matrix #2897 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/2897/])
HBASE-17943 The in-memory flush size is different for each (chia7712: rev 
ea3a27b18df875284899b04fbc5fb58a3120e6c7)
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/CompactingMemStore.java
* (edit) 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RegionServicesForStores.java
* (edit) 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestWalAndCompactingMemStoreFlush.java


> The in-memory flush size is different for each CompactingMemStore located in 
> the same region 
> -
>
> Key: HBASE-17943
> URL: https://issues.apache.org/jira/browse/HBASE-17943
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 2.0.0
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
> Fix For: 2.0.0
>
> Attachments: HBASE-17943.v0.patch
>
>
> {noformat}
>   private void initInmemoryFlushSize(Configuration conf) {
> long memstoreFlushSize = getRegionServices().getMemstoreFlushSize();
> int numStores = getRegionServices().getNumStores();
> if (numStores <= 1) {
>   // Family number might also be zero in some of our unit test case
>   numStores = 1;
> }
> inmemoryFlushSize = memstoreFlushSize / numStores;
> {noformat}
> We initialize each store in parallel, so the return value from getNumStores() 
> may be different for each CompactingMemStore.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Comment Edited] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Colm O hEigeartaigh (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978282#comment-15978282
 ] 

Colm O hEigeartaigh edited comment on HBASE-17944 at 4/21/17 8:18 AM:
--

OK I have submitted a patch to remove the static block. Even on 1.1.x the JDK7 
variable is not used, so the patch can be backported there as well.

[~tedyu], no I am not deploying Java 9 in my cluster :-) I am trying to get 
Apache Ranger, which has a HBase 1.1.x dependency, working with Java 9. After 
this fix the tests pass correctly.


was (Author: coheigea):
OK I will submit two patches. One to remove the JDK7 property which should be 
applied to master, and back to 1.2.x. And one patch for 1.1.x which allows it 
to work with Java 9.

[~tedyu], no I am not deploying Java 9 in my cluster :-) I am trying to get 
Apache Ranger, which has a HBase 1.1.x dependency, working with Java 9. After 
this fix the tests pass correctly.

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Colm O hEigeartaigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated HBASE-17944:

Attachment: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Colm O hEigeartaigh (JIRA)

 [ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colm O hEigeartaigh updated HBASE-17944:

Attachment: (was: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch)

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (HBASE-17944) ClassSize fails with Java 9

2017-04-21 Thread Colm O hEigeartaigh (JIRA)

[ 
https://issues.apache.org/jira/browse/HBASE-17944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15978282#comment-15978282
 ] 

Colm O hEigeartaigh commented on HBASE-17944:
-

OK I will submit two patches. One to remove the JDK7 property which should be 
applied to master, and back to 1.2.x. And one patch for 1.1.x which allows it 
to work with Java 9.

[~tedyu], no I am not deploying Java 9 in my cluster :-) I am trying to get 
Apache Ranger, which has a HBase 1.1.x dependency, working with Java 9. After 
this fix the tests pass correctly.

> ClassSize fails with Java 9
> ---
>
> Key: HBASE-17944
> URL: https://issues.apache.org/jira/browse/HBASE-17944
> Project: HBase
>  Issue Type: Bug
>Reporter: Colm O hEigeartaigh
> Fix For: 2.0.0, 1.1.10, 1.2.6, 1.3.2
>
> Attachments: 0001-HBASE-17944-ClassSize-fails-with-Java-9.patch
>
>
> ClassSize fails when run with Java 9. The static block assumes that the java 
> version contains "." which is not necessarily the case with Java 9:
> Caused by: java.lang.RuntimeException: Unexpected version format: 9-ea
>   at org.apache.hadoop.hbase.util.ClassSize.(ClassSize.java:119)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


  1   2   >