[jira] [Reopened] (HBASE-21094) Remove the explicit timeout config for TestTruncateTableProcedure

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-21094:


Reopen for revert and change Jira number in commit message.

> Remove the explicit timeout config for TestTruncateTableProcedure
> -
>
> Key: HBASE-21094
> URL: https://issues.apache.org/jira/browse/HBASE-21094
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>
> Attachments: HBASE-21094.patch
>
>
> Skimmed the logs of a failing run on flaky dashboard, seems no problem, just 
> a bit slow. Let's remove the (timeout = 6) for all the tests.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21717:
---

Review board link:

https://reviews.apache.org/r/70107/

> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch, 
> HBASE-21717-HBASE-21512-v2.patch, HBASE-21717-HBASE-21512-v3.patch, 
> HBASE-21717-HBASE-21512-v4.patch, HBASE-21717-HBASE-21512-v5.patch, 
> HBASE-21717-HBASE-21512-v6.patch, HBASE-21717-HBASE-21512-v7.patch, 
> HBASE-21717-HBASE-21512.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21717:
---

The failed UTs can pass locally, a bit strange...

> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch, 
> HBASE-21717-HBASE-21512-v2.patch, HBASE-21717-HBASE-21512-v3.patch, 
> HBASE-21717-HBASE-21512-v4.patch, HBASE-21717-HBASE-21512-v5.patch, 
> HBASE-21717-HBASE-21512-v6.patch, HBASE-21717-HBASE-21512-v7.patch, 
> HBASE-21717-HBASE-21512.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (HBASE-21093) Move TestCreateTableProcedure.testMRegions to a separated file

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-21093:


Reopen for change the Jira number in commit message.

> Move TestCreateTableProcedure.testMRegions to a separated file
> --
>
> Key: HBASE-21093
> URL: https://issues.apache.org/jira/browse/HBASE-21093
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>
> Attachments: HBASE-21093-v1.patch, HBASE-21093.patch
>
>
> In TestTableDDLProcedureBase we set the procedure worker number to 1, so on a 
> slow machine, we will fail to batch the remote calls to RS with the default 
> dispatch delay, and lead to a very long time to finish the bunch of sub TRSPs.
> Edit:
> It seems that the problem is that, we are slow when updating procedure store 
> sometimes. This is not easy to fix so move testMRegions to separated file 
> first.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang updated HBASE-21717:
--
Attachment: HBASE-21717-HBASE-21512-v7.patch

> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch, 
> HBASE-21717-HBASE-21512-v2.patch, HBASE-21717-HBASE-21512-v3.patch, 
> HBASE-21717-HBASE-21512-v4.patch, HBASE-21717-HBASE-21512-v5.patch, 
> HBASE-21717-HBASE-21512-v6.patch, HBASE-21717-HBASE-21512-v7.patch, 
> HBASE-21717-HBASE-21512.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-18201) add UT and docs for DataBlockEncodingTool

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang resolved HBASE-18201.

Resolution: Fixed

> add UT and docs for DataBlockEncodingTool
> -
>
> Key: HBASE-18201
> URL: https://issues.apache.org/jira/browse/HBASE-18201
> Project: HBase
>  Issue Type: Sub-task
>  Components: tooling
>Reporter: Chia-Ping Tsai
>Assignee: Kuan-Po Tseng
>Priority: Minor
>  Labels: beginner
> Fix For: 3.0.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-18201.master.001.patch, 
> HBASE-18201.master.002.patch, HBASE-18201.master.002.patch, 
> HBASE-18201.master.003.patch, HBASE-18201.master.004.patch, 
> HBASE-18201.master.005.patch, HBASE-18201.master.005.patch, 
> HBASE-18201.master.005.patch, HBASE-18201.master.006.patch, 
> HBASE-18201.master.006.patch
>
>
> There is no example, documents, or tests for DataBlockEncodingTool. We should 
> have it friendly if any use case exists. Otherwise, we should just get rid of 
> it because DataBlockEncodingTool presumes that the implementation of cell 
> returned from DataBlockEncoder is KeyValue. The presume may obstruct the 
> cleanup of KeyValue references in the code base of read/write path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (HBASE-18201) add UT and docs for DataBlockEncodingTool

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-18201:


> add UT and docs for DataBlockEncodingTool
> -
>
> Key: HBASE-18201
> URL: https://issues.apache.org/jira/browse/HBASE-18201
> Project: HBase
>  Issue Type: Sub-task
>  Components: tooling
>Reporter: Chia-Ping Tsai
>Assignee: Kuan-Po Tseng
>Priority: Minor
>  Labels: beginner
> Fix For: 3.0.0, 2.2.0, 2.1.1
>
> Attachments: HBASE-18201.master.001.patch, 
> HBASE-18201.master.002.patch, HBASE-18201.master.002.patch, 
> HBASE-18201.master.003.patch, HBASE-18201.master.004.patch, 
> HBASE-18201.master.005.patch, HBASE-18201.master.005.patch, 
> HBASE-18201.master.005.patch, HBASE-18201.master.006.patch, 
> HBASE-18201.master.006.patch
>
>
> There is no example, documents, or tests for DataBlockEncodingTool. We should 
> have it friendly if any use case exists. Otherwise, we should just get rid of 
> it because DataBlockEncodingTool presumes that the implementation of cell 
> returned from DataBlockEncoder is KeyValue. The presume may obstruct the 
> cleanup of KeyValue references in the code base of read/write path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21871) Support to specify a peer table name in VerifyReplication tool

2019-03-03 Thread Subrat Mishra (JIRA)


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

Subrat Mishra updated HBASE-21871:
--
Status: Patch Available  (was: Open)

> Support to specify a peer table name in VerifyReplication tool
> --
>
> Key: HBASE-21871
> URL: https://issues.apache.org/jira/browse/HBASE-21871
> Project: HBase
>  Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Subrat Mishra
>Priority: Major
> Attachments: HBASE-21871.master.001.patch
>
>
> After HBASE-21201, we can specify peerQuorumAddress instead of peerId in 
> VerifyReplication tool. So it no longer requires peerId to be setup when 
> using this tool. However, we don't have a way to specify a peer table name in 
> VerifyReplication for now.
> So I would like to propose to update the tool to pass as a peer table name as 
> an argument (ex. --peerTableName=).
> After resolving this Jira, we will be able to compare any 2 tables in any 
> remote clusters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21981) MMaped bucket cache IOEngine does not work with persistence

2019-03-03 Thread Anoop Sam John (JIRA)


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

Anoop Sam John commented on HBASE-21981:


Wait let me do a reverse way...  will report back soon Duo. Tks

> MMaped bucket cache IOEngine does not work with persistence
> ---
>
> Key: HBASE-21981
> URL: https://issues.apache.org/jira/browse/HBASE-21981
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.1.3
>Reporter: ramkrishna.s.vasudevan
>Assignee: Anoop Sam John
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21981.patch, HBASE-21981.patch
>
>
> The MMap based IOEngines does not retrieve the data back if 
> 'hbase.bucketcache.persistent.path' is enabled. FileIOEngine works fine but 
> only the FileMMapEngine has this problem.
> The reason is that we don't get the byte buffers in the proper order while 
> reading back from the file in case of persistence.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21871) Support to specify a peer table name in VerifyReplication tool

2019-03-03 Thread Subrat Mishra (JIRA)


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

Subrat Mishra updated HBASE-21871:
--
Attachment: HBASE-21871.master.001.patch

> Support to specify a peer table name in VerifyReplication tool
> --
>
> Key: HBASE-21871
> URL: https://issues.apache.org/jira/browse/HBASE-21871
> Project: HBase
>  Issue Type: Improvement
>Reporter: Toshihiro Suzuki
>Assignee: Subrat Mishra
>Priority: Major
> Attachments: HBASE-21871.master.001.patch
>
>
> After HBASE-21201, we can specify peerQuorumAddress instead of peerId in 
> VerifyReplication tool. So it no longer requires peerId to be setup when 
> using this tool. However, we don't have a way to specify a peer table name in 
> VerifyReplication for now.
> So I would like to propose to update the tool to pass as a peer table name as 
> an argument (ex. --peerTableName=).
> After resolving this Jira, we will be able to compare any 2 tables in any 
> remote clusters.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21981) MMaped bucket cache IOEngine does not work with persistence

2019-03-03 Thread Anoop Sam John (JIRA)


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

Anoop Sam John commented on HBASE-21981:


It has to be either an index or a global offset number. (offset of this BB in 
the entire BC space).   The multi threading way really helps when the size of 
the cache is big.. 

> MMaped bucket cache IOEngine does not work with persistence
> ---
>
> Key: HBASE-21981
> URL: https://issues.apache.org/jira/browse/HBASE-21981
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.1.3
>Reporter: ramkrishna.s.vasudevan
>Assignee: Anoop Sam John
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21981.patch, HBASE-21981.patch
>
>
> The MMap based IOEngines does not retrieve the data back if 
> 'hbase.bucketcache.persistent.path' is enabled. FileIOEngine works fine but 
> only the FileMMapEngine has this problem.
> The reason is that we don't get the byte buffers in the proper order while 
> reading back from the file in case of persistence.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-15557) Add guidance on HashTable/SyncTable to the RefGuide

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang updated HBASE-15557:
---
Fix Version/s: 2.2.0

> Add guidance on HashTable/SyncTable to the RefGuide
> ---
>
> Key: HBASE-15557
> URL: https://issues.apache.org/jira/browse/HBASE-15557
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 1.2.0
>Reporter: Sean Busbey
>Assignee: Wellington Chevreuil
>Priority: Critical
> Fix For: 3.0.0, 2.2.0
>
> Attachments: HBASE-15557.master.001.patch, 
> HBASE-15557.master.002.patch
>
>
> The docs for SyncTable are insufficient. Brief description from [~davelatham] 
> HBASE-13639 comment:
> {quote}
> Sorry for the lack of better documentation, Abhishek Soni. Thanks for 
> bringing it up. I'll try to provide a better explanation. You may have 
> already seen it, but if not, the design doc linked in the description above 
> may also give you some better clues as to how it should be used.
> Briefly, the feature is intended to start with a pair of tables in remote 
> clusters that are already substantially similar and make them identical by 
> comparing hashes of the data and copying only the diffs instead of having to 
> copy the entire table. So it is targeted at a very specific use case (with 
> some work it could generalize to cover things like CopyTable and 
> VerifyRepliaction but it's not there yet). To use it, you choose one table to 
> be the "source", and the other table is the "target". After the process is 
> complete the target table should end up being identical to the source table.
> In the source table's cluster, run 
> org.apache.hadoop.hbase.mapreduce.HashTable and pass it the name of the 
> source table and an output directory in HDFS. HashTable will scan the source 
> table, break the data up into row key ranges (default of 8kB per range) and 
> produce a hash of the data for each range.
> Make the hashes available to the target cluster - I'd recommend using DistCp 
> to copy it across.
> In the target table's cluster, run 
> org.apache.hadoop.hbase.mapreduce.SyncTable and pass it the directory where 
> you put the hashes, and the names of the source and destination tables. You 
> will likely also need to specify the source table's ZK quorum via the 
> --sourcezkcluster option. SyncTable will then read the hash information, and 
> compute the hashes of the same row ranges for the target table. For any row 
> range where the hash fails to match, it will open a remote scanner to the 
> source table, read the data for that range, and do Puts and Deletes to the 
> target table to update it to match the source.
> I hope that clarifies it a bit. Let me know if you need a hand. If anyone 
> wants to work on getting some documentation into the book, I can try to write 
> some more but would love a hand on turning it into an actual book patch.
> {quote}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (HBASE-21740) NPE happens while shutdown the RS

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-21740:


Reopen for branch-2.2.

> NPE happens while shutdown the RS
> -
>
> Key: HBASE-21740
> URL: https://issues.apache.org/jira/browse/HBASE-21740
> Project: HBase
>  Issue Type: Bug
>Reporter: lujie
>Assignee: lujie
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0
>
> Attachments: 0001-fix-HBASE-21740.patch, HBASE-21740_1.patch, 
> HBASE-21740_2.patch, HBASE-21740_branch_1.4_1.patch, 
> HBASE-21740_branch_2.1_2.patch
>
>
> while shutdown a NM, we meet a NPE:
> {code:java}
> 2019-01-18 16:52:05,500 INFO [Thread-4] regionserver.HRegionServer: STOPPED: 
> Shutdown hook
> 2019-01-18 16:52:05,896 INFO [regionserver/hadoop15:16020] 
> regionserver.MetricsRegionServerWrapperImpl: Computing regionserver metrics 
> every 5000 milliseconds
> 2019-01-18 16:52:05,978 INFO [regionserver/hadoop15:16020.Chore.1] 
> hbase.ScheduledChore: Chore: CompactedHFilesCleaner was stopped
> 2019-01-18 16:52:05,996 ERROR [regionserver/hadoop15:16020] 
> regionserver.HRegionServer: Failed init
> java.lang.NullPointerException
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.startServices(HRegionServer.java:1978)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1572)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:975)
> at java.lang.Thread.run(Thread.java:745)
> 2019-01-18 16:52:06,011 ERROR [regionserver/hadoop15:16020] 
> regionserver.HRegionServer: * ABORTING region server 
> hadoop15,16020,1547801516426: Unhandled: Region server startup failed *
> java.io.IOException: Region server startup failed
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:3392)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1591)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:975)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.startServices(HRegionServer.java:1978)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1572)
> ... 2 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-21740) NPE happens while shutdown the RS

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang resolved HBASE-21740.

   Resolution: Fixed
Fix Version/s: 2.3.0

Pushed to branch-2.2.

> NPE happens while shutdown the RS
> -
>
> Key: HBASE-21740
> URL: https://issues.apache.org/jira/browse/HBASE-21740
> Project: HBase
>  Issue Type: Bug
>Reporter: lujie
>Assignee: lujie
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0, 1.5.0
>
> Attachments: 0001-fix-HBASE-21740.patch, HBASE-21740_1.patch, 
> HBASE-21740_2.patch, HBASE-21740_branch_1.4_1.patch, 
> HBASE-21740_branch_2.1_2.patch
>
>
> while shutdown a NM, we meet a NPE:
> {code:java}
> 2019-01-18 16:52:05,500 INFO [Thread-4] regionserver.HRegionServer: STOPPED: 
> Shutdown hook
> 2019-01-18 16:52:05,896 INFO [regionserver/hadoop15:16020] 
> regionserver.MetricsRegionServerWrapperImpl: Computing regionserver metrics 
> every 5000 milliseconds
> 2019-01-18 16:52:05,978 INFO [regionserver/hadoop15:16020.Chore.1] 
> hbase.ScheduledChore: Chore: CompactedHFilesCleaner was stopped
> 2019-01-18 16:52:05,996 ERROR [regionserver/hadoop15:16020] 
> regionserver.HRegionServer: Failed init
> java.lang.NullPointerException
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.startServices(HRegionServer.java:1978)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1572)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:975)
> at java.lang.Thread.run(Thread.java:745)
> 2019-01-18 16:52:06,011 ERROR [regionserver/hadoop15:16020] 
> regionserver.HRegionServer: * ABORTING region server 
> hadoop15,16020,1547801516426: Unhandled: Region server startup failed *
> java.io.IOException: Region server startup failed
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.convertThrowableToIOE(HRegionServer.java:3392)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1591)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.run(HRegionServer.java:975)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.startServices(HRegionServer.java:1978)
> at 
> org.apache.hadoop.hbase.regionserver.HRegionServer.handleReportForDutyResponse(HRegionServer.java:1572)
> ... 2 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-21016) Find another way to test the backoff mechanism in TRSP

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang resolved HBASE-21016.

   Resolution: Duplicate
Fix Version/s: (was: 2.2.0)
   (was: 3.0.0)

Resolve as duplicate.

> Find another way to test the backoff mechanism in TRSP
> --
>
> Key: HBASE-21016
> URL: https://issues.apache.org/jira/browse/HBASE-21016
> Project: HBase
>  Issue Type: Sub-task
>  Components: amv2, test
>Reporter: Duo Zhang
>Priority: Major
>
> The old way in TestUnexpectedStateException does not work any more. Need to 
> find another way to throwing IOException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (HBASE-21016) Find another way to test the backoff mechanism in TRSP

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-21016:


> Find another way to test the backoff mechanism in TRSP
> --
>
> Key: HBASE-21016
> URL: https://issues.apache.org/jira/browse/HBASE-21016
> Project: HBase
>  Issue Type: Sub-task
>  Components: amv2, test
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0
>
>
> The old way in TestUnexpectedStateException does not work any more. Need to 
> find another way to throwing IOException.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21093) Move TestCreateTableProcedure.testMRegions to a separated file

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang commented on HBASE-21093:


Seems this only pushed to master? But the commit message is not same with the 
Jira title.

commit c01d4d3a35a53d67d4106fc906629413f8e980a7
Author: Duo Zhang 
Date: Wed Aug 22 10:43:25 2018 +0800

HBASE-21093 Increase the dispatch delay for testing DDL procedures

> Move TestCreateTableProcedure.testMRegions to a separated file
> --
>
> Key: HBASE-21093
> URL: https://issues.apache.org/jira/browse/HBASE-21093
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>
> Attachments: HBASE-21093-v1.patch, HBASE-21093.patch
>
>
> In TestTableDDLProcedureBase we set the procedure worker number to 1, so on a 
> slow machine, we will fail to batch the remote calls to RS with the default 
> dispatch delay, and lead to a very long time to finish the bunch of sub TRSPs.
> Edit:
> It seems that the problem is that, we are slow when updating procedure store 
> sometimes. This is not easy to fix so move testMRegions to separated file 
> first.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21093) Move TestCreateTableProcedure.testMRegions to a separated file

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang commented on HBASE-21093:


Ping [~Apache9]

> Move TestCreateTableProcedure.testMRegions to a separated file
> --
>
> Key: HBASE-21093
> URL: https://issues.apache.org/jira/browse/HBASE-21093
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.1.1, 2.0.2
>
> Attachments: HBASE-21093-v1.patch, HBASE-21093.patch
>
>
> In TestTableDDLProcedureBase we set the procedure worker number to 1, so on a 
> slow machine, we will fail to batch the remote calls to RS with the default 
> dispatch delay, and lead to a very long time to finish the bunch of sub TRSPs.
> Edit:
> It seems that the problem is that, we are slow when updating procedure store 
> sometimes. This is not easy to fix so move testMRegions to separated file 
> first.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-21866) Do not move the table to null rsgroup when creating an existing table

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang resolved HBASE-21866.

   Resolution: Fixed
Fix Version/s: 2.3.0

Pushed to branch-2.2.

> Do not move the table to null rsgroup when creating an existing table
> -
>
> Key: HBASE-21866
> URL: https://issues.apache.org/jira/browse/HBASE-21866
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2, rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0, 1.5.0
>
> Attachments: HBASE-21866.branch-1.000.patch, 
> HBASE-21866.branch-2.000.patch, HBASE-21866.master.000.patch, 
> HBASE-21866.master.001.patch, HBASE-21866.master.002.patch, 
> HBASE-21866.master.003.patch, HBASE-21866.master.003.patch, 
> HBASE-21866.master.003.patch
>
>
> By using the latest HBase master branch, the bug could be re-produced as:
>  # create 't1', 'cf1'
>  # create 't1', 'cf1'
> The following message is logged into HMaster's log:
> {code}
> INFO  [PEWorker-12] rsgroup.RSGroupAdminServer: Moving table t1 to RSGroup 
> null
> {code}
> This is a wrong action and instead, we should keep t1 as where it originally 
> is.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21866) Do not move the table to null rsgroup when creating an existing table

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang commented on HBASE-21866:


 [~xucang] please commit to branch-2.2, too if there are issues fix version is 
for 2.2.0. And please commit with --signoff if you help to commit. Thanks.

> Do not move the table to null rsgroup when creating an existing table
> -
>
> Key: HBASE-21866
> URL: https://issues.apache.org/jira/browse/HBASE-21866
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2, rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21866.branch-1.000.patch, 
> HBASE-21866.branch-2.000.patch, HBASE-21866.master.000.patch, 
> HBASE-21866.master.001.patch, HBASE-21866.master.002.patch, 
> HBASE-21866.master.003.patch, HBASE-21866.master.003.patch, 
> HBASE-21866.master.003.patch
>
>
> By using the latest HBase master branch, the bug could be re-produced as:
>  # create 't1', 'cf1'
>  # create 't1', 'cf1'
> The following message is logged into HMaster's log:
> {code}
> INFO  [PEWorker-12] rsgroup.RSGroupAdminServer: Moving table t1 to RSGroup 
> null
> {code}
> This is a wrong action and instead, we should keep t1 as where it originally 
> is.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21981) MMaped bucket cache IOEngine does not work with persistence

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21981:
---

Having a index parameter for an allocator is weird... Do we have other 
solutions?

> MMaped bucket cache IOEngine does not work with persistence
> ---
>
> Key: HBASE-21981
> URL: https://issues.apache.org/jira/browse/HBASE-21981
> Project: HBase
>  Issue Type: Bug
>  Components: BucketCache
>Affects Versions: 2.1.3
>Reporter: ramkrishna.s.vasudevan
>Assignee: Anoop Sam John
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.3.0, 2.1.4
>
> Attachments: HBASE-21981.patch, HBASE-21981.patch
>
>
> The MMap based IOEngines does not retrieve the data back if 
> 'hbase.bucketcache.persistent.path' is enabled. FileIOEngine works fine but 
> only the FileMMapEngine has this problem.
> The reason is that we don't get the byte buffers in the proper order while 
> reading back from the file in case of persistence.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Reopened] (HBASE-21866) Do not move the table to null rsgroup when creating an existing table

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-21866:


Reopen for branch-2.2.

> Do not move the table to null rsgroup when creating an existing table
> -
>
> Key: HBASE-21866
> URL: https://issues.apache.org/jira/browse/HBASE-21866
> Project: HBase
>  Issue Type: Bug
>  Components: proc-v2, rsgroup
>Reporter: Xiang Li
>Assignee: Xiang Li
>Priority: Major
> Fix For: 3.0.0, 1.5.0, 2.2.0
>
> Attachments: HBASE-21866.branch-1.000.patch, 
> HBASE-21866.branch-2.000.patch, HBASE-21866.master.000.patch, 
> HBASE-21866.master.001.patch, HBASE-21866.master.002.patch, 
> HBASE-21866.master.003.patch, HBASE-21866.master.003.patch, 
> HBASE-21866.master.003.patch
>
>
> By using the latest HBase master branch, the bug could be re-produced as:
>  # create 't1', 'cf1'
>  # create 't1', 'cf1'
> The following message is logged into HMaster's log:
> {code}
> INFO  [PEWorker-12] rsgroup.RSGroupAdminServer: Moving table t1 to RSGroup 
> null
> {code}
> This is a wrong action and instead, we should keep t1 as where it originally 
> is.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21934) RemoteProcedureDispatcher should track the ongoing dispatched calls

2019-03-03 Thread Jingyun Tian (JIRA)


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

Jingyun Tian updated HBASE-21934:
-
Attachment: HBASE-21934.branch-2.1.003.patch

> RemoteProcedureDispatcher should track the ongoing dispatched calls
> ---
>
> Key: HBASE-21934
> URL: https://issues.apache.org/jira/browse/HBASE-21934
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.x
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21934.branch-2.001.patch, 
> HBASE-21934.branch-2.1.001.patch, HBASE-21934.branch-2.1.001.patch, 
> HBASE-21934.branch-2.1.002.patch, HBASE-21934.branch-2.1.003.patch, 
> HBASE-21934.branch-2.2.001.patch, HBASE-21934.master.001.patch, 
> HBASE-21934.master.002.patch, HBASE-21934.master.003.patch, 
> HBASE-21934.master.004.patch, HBASE-21934.master.005.patch, 
> HBASE-21934.master.006.patch, HBASE-21934.master.007.patch, 
> HBASE-21934.master.008.patch, HBASE-21934.master.009.patch
>
>
> I encounter the problem that when master assign a splitWALRemoteProcedure to 
> a region server. The log of this region server says it failed to recover the 
> lease of this file. Then this region server is killed by chaosMonkey. As the 
> result, this procedure is not timeout and hang there forever.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21145) Backport "HBASE-21126 Add ability for HBase Canary to ignore a configurable number of ZooKeeper down nodes" to branch-2.1

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang updated HBASE-21145:
---
Fix Version/s: (was: 2.2.0)
   (was: 3.0.0)

> Backport "HBASE-21126 Add ability for HBase Canary to ignore a configurable 
> number of ZooKeeper down nodes" to branch-2.1
> -
>
> Key: HBASE-21145
> URL: https://issues.apache.org/jira/browse/HBASE-21145
> Project: HBase
>  Issue Type: Improvement
>  Components: canary, Zookeeper
>Affects Versions: 1.0.0, 3.0.0, 2.0.0
>Reporter: David Manning
>Assignee: Duo Zhang
>Priority: Minor
> Fix For: 2.1.1
>
> Attachments: HBASE-21126.branch-1.001.patch, 
> HBASE-21126.master.001.patch, HBASE-21126.master.002.patch, 
> HBASE-21126.master.003.patch, zookeeperCanaryLocalTestValidation.txt
>
>   Original Estimate: 48h
>  Remaining Estimate: 48h
>
> When running org.apache.hadoop.hbase.tool.Canary with args -zookeeper 
> -treatFailureAsError, the Canary will try to get a znode from each ZooKeeper 
> server in the ensemble. If any server is unavailable or unresponsive, the 
> canary will exit with a failure code.
> If we use the Canary to gauge server health, and alert accordingly, this can 
> be too strict. For example, in a 5-node ZooKeeper cluster, having one node 
> down is safe and expected in rolling upgrades/patches.
> This is a request to allow the Canary to take another parameter
> {code:java}
> -permittedZookeeperFailures {code}
> If N=1, in the 5-node ZooKeeper ensemble example, then the Canary will still 
> pass if 4 ZooKeeper nodes are reachable, but fail if 3 or fewer are reachable.
> (This is my first Jira posting... sorry if I messed anything up.)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Resolved] (HBASE-14223) Meta WALs are not cleared if meta region was closed and RS aborts

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang resolved HBASE-14223.

Resolution: Duplicate

Resolve as duplicate.

> Meta WALs are not cleared if meta region was closed and RS aborts
> -
>
> Key: HBASE-14223
> URL: https://issues.apache.org/jira/browse/HBASE-14223
> Project: HBase
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Major
> Attachments: HBASE-14223logs, hbase-14223_v0.patch, 
> hbase-14223_v1-branch-1.patch, hbase-14223_v2-branch-1.patch, 
> hbase-14223_v3-branch-1.patch, hbase-14223_v3-branch-1.patch, 
> hbase-14223_v3-master.patch
>
>
> When an RS opens meta, and later closes it, the WAL(FSHlog) is not closed. 
> The last WAL file just sits there in the RS WAL directory. If RS stops 
> gracefully, the WAL file for meta is deleted. Otherwise if RS aborts, WAL for 
> meta is not cleaned. It is also not split (which is correct) since master 
> determines that the RS no longer hosts meta at the time of RS abort. 
> From a cluster after running ITBLL with CM, I see a lot of {{-splitting}} 
> directories left uncleaned: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs
> Found 31 items
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 01:14 
> /apps/hbase/data/WALs/hregion-58203265
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 07:54 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433489308745-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 09:28 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433494382959-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 10:01 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433498252205-splitting
> ...
> {code}
> The directories contain WALs from meta: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting
> Found 2 items
> -rw-r--r--   3 hbase hadoop 201608 2015-06-05 03:15 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
> -rw-r--r--   3 hbase hadoop  44420 2015-06-05 04:36 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> The RS hosted the meta region for some time: 
> {code}
> 2015-06-05 03:14:28,692 INFO  [PostOpenDeployTasks:1588230740] 
> zookeeper.MetaTableLocator: Setting hbase:meta region location in ZooKeeper 
> as os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285
> ...
> 2015-06-05 03:15:17,302 INFO  
> [RS_CLOSE_META-os-enis-dal-test-jun-4-5:16020-0] regionserver.HRegion: Closed 
> hbase:meta,,1.1588230740
> {code}
> In between, a WAL is created: 
> {code}
> 2015-06-05 03:15:11,707 INFO  
> [RS_OPEN_META-os-enis-dal-test-jun-4-5:16020-0-MetaLogRoller] wal.FSHLog: 
> Rolled WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
>  with entries=385, filesize=196.88 KB; new WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> When CM killed the region server later master did not see these WAL files: 
> {code}
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:46,075 
> INFO  [MASTER_SERVER_OPERATIONS-os-enis-dal-test-jun-4-3:16000-0] 
> master.SplitLogManager: started splitting 2 logs in 
> [hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting]
>  for [os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285]
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:47,300 
> INFO  [main-EventThread] wal.WALSplitter: Archived processed log 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
>  to 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/oldWALs/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:50,497 
> INFO  [main-EventThread] wal.WALSplitter: Archived processed log 
> 

[jira] [Reopened] (HBASE-14223) Meta WALs are not cleared if meta region was closed and RS aborts

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang reopened HBASE-14223:


> Meta WALs are not cleared if meta region was closed and RS aborts
> -
>
> Key: HBASE-14223
> URL: https://issues.apache.org/jira/browse/HBASE-14223
> Project: HBase
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Major
> Attachments: HBASE-14223logs, hbase-14223_v0.patch, 
> hbase-14223_v1-branch-1.patch, hbase-14223_v2-branch-1.patch, 
> hbase-14223_v3-branch-1.patch, hbase-14223_v3-branch-1.patch, 
> hbase-14223_v3-master.patch
>
>
> When an RS opens meta, and later closes it, the WAL(FSHlog) is not closed. 
> The last WAL file just sits there in the RS WAL directory. If RS stops 
> gracefully, the WAL file for meta is deleted. Otherwise if RS aborts, WAL for 
> meta is not cleaned. It is also not split (which is correct) since master 
> determines that the RS no longer hosts meta at the time of RS abort. 
> From a cluster after running ITBLL with CM, I see a lot of {{-splitting}} 
> directories left uncleaned: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs
> Found 31 items
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 01:14 
> /apps/hbase/data/WALs/hregion-58203265
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 07:54 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433489308745-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 09:28 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433494382959-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 10:01 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433498252205-splitting
> ...
> {code}
> The directories contain WALs from meta: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting
> Found 2 items
> -rw-r--r--   3 hbase hadoop 201608 2015-06-05 03:15 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
> -rw-r--r--   3 hbase hadoop  44420 2015-06-05 04:36 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> The RS hosted the meta region for some time: 
> {code}
> 2015-06-05 03:14:28,692 INFO  [PostOpenDeployTasks:1588230740] 
> zookeeper.MetaTableLocator: Setting hbase:meta region location in ZooKeeper 
> as os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285
> ...
> 2015-06-05 03:15:17,302 INFO  
> [RS_CLOSE_META-os-enis-dal-test-jun-4-5:16020-0] regionserver.HRegion: Closed 
> hbase:meta,,1.1588230740
> {code}
> In between, a WAL is created: 
> {code}
> 2015-06-05 03:15:11,707 INFO  
> [RS_OPEN_META-os-enis-dal-test-jun-4-5:16020-0-MetaLogRoller] wal.FSHLog: 
> Rolled WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
>  with entries=385, filesize=196.88 KB; new WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> When CM killed the region server later master did not see these WAL files: 
> {code}
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:46,075 
> INFO  [MASTER_SERVER_OPERATIONS-os-enis-dal-test-jun-4-3:16000-0] 
> master.SplitLogManager: started splitting 2 logs in 
> [hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting]
>  for [os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285]
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:47,300 
> INFO  [main-EventThread] wal.WALSplitter: Archived processed log 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
>  to 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/oldWALs/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:50,497 
> INFO  [main-EventThread] wal.WALSplitter: Archived processed log 
> 

[jira] [Updated] (HBASE-14223) Meta WALs are not cleared if meta region was closed and RS aborts

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang updated HBASE-14223:
---
Fix Version/s: (was: 2.2.0)
   (was: 1.5.0)
   (was: 3.0.0)

> Meta WALs are not cleared if meta region was closed and RS aborts
> -
>
> Key: HBASE-14223
> URL: https://issues.apache.org/jira/browse/HBASE-14223
> Project: HBase
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
>Priority: Major
> Attachments: HBASE-14223logs, hbase-14223_v0.patch, 
> hbase-14223_v1-branch-1.patch, hbase-14223_v2-branch-1.patch, 
> hbase-14223_v3-branch-1.patch, hbase-14223_v3-branch-1.patch, 
> hbase-14223_v3-master.patch
>
>
> When an RS opens meta, and later closes it, the WAL(FSHlog) is not closed. 
> The last WAL file just sits there in the RS WAL directory. If RS stops 
> gracefully, the WAL file for meta is deleted. Otherwise if RS aborts, WAL for 
> meta is not cleaned. It is also not split (which is correct) since master 
> determines that the RS no longer hosts meta at the time of RS abort. 
> From a cluster after running ITBLL with CM, I see a lot of {{-splitting}} 
> directories left uncleaned: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs
> Found 31 items
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 01:14 
> /apps/hbase/data/WALs/hregion-58203265
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 07:54 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433489308745-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 09:28 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433494382959-splitting
> drwxr-xr-x   - hbase hadoop  0 2015-06-05 10:01 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-1.openstacklocal,16020,1433498252205-splitting
> ...
> {code}
> The directories contain WALs from meta: 
> {code}
> [root@os-enis-dal-test-jun-4-7 cluster-os]# sudo -u hdfs hadoop fs -ls 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting
> Found 2 items
> -rw-r--r--   3 hbase hadoop 201608 2015-06-05 03:15 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
> -rw-r--r--   3 hbase hadoop  44420 2015-06-05 04:36 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> The RS hosted the meta region for some time: 
> {code}
> 2015-06-05 03:14:28,692 INFO  [PostOpenDeployTasks:1588230740] 
> zookeeper.MetaTableLocator: Setting hbase:meta region location in ZooKeeper 
> as os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285
> ...
> 2015-06-05 03:15:17,302 INFO  
> [RS_CLOSE_META-os-enis-dal-test-jun-4-5:16020-0] regionserver.HRegion: Closed 
> hbase:meta,,1.1588230740
> {code}
> In between, a WAL is created: 
> {code}
> 2015-06-05 03:15:11,707 INFO  
> [RS_OPEN_META-os-enis-dal-test-jun-4-5:16020-0-MetaLogRoller] wal.FSHLog: 
> Rolled WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433470511501.meta
>  with entries=385, filesize=196.88 KB; new WAL 
> /apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285..meta.1433474111645.meta
> {code}
> When CM killed the region server later master did not see these WAL files: 
> {code}
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:46,075 
> INFO  [MASTER_SERVER_OPERATIONS-os-enis-dal-test-jun-4-3:16000-0] 
> master.SplitLogManager: started splitting 2 logs in 
> [hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting]
>  for [os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285]
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:47,300 
> INFO  [main-EventThread] wal.WALSplitter: Archived processed log 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/WALs/os-enis-dal-test-jun-4-5.openstacklocal,16020,1433466904285-splitting/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
>  to 
> hdfs://os-enis-dal-test-jun-4-1.openstacklocal:8020/apps/hbase/data/oldWALs/os-enis-dal-test-jun-4-5.openstacklocal%2C16020%2C1433466904285.default.1433475074436
> ./hbase-hbase-master-os-enis-dal-test-jun-4-3.log:2015-06-05 03:36:50,497 
> INFO  

[jira] [Commented] (HBASE-21934) RemoteProcedureDispatcher should track the ongoing dispatched calls

2019-03-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-21934:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:brown} branch-2.1 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
16s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 5s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
21s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
28s{color} | {color:green} branch-2.1 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 7s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  2m  
8s{color} | {color:blue} hbase-server in branch-2.1 has 1 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
42s{color} | {color:green} branch-2.1 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
14s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
21s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
21s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  1m 
15s{color} | {color:red} hbase-server: The patch generated 1 new + 3 unchanged 
- 0 fixed = 4 total (was 3) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 1s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 6s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 17s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
56s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
41s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  3m 
18s{color} | {color:green} hbase-procedure in the patch passed. {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red}138m 37s{color} 
| {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
43s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}183m 14s{color} | 
{color:black} {color} |
\\
\\
|| Reason || Tests ||
| Failed junit tests | hadoop.hbase.master.TestDLSFSHLog |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-21934 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12960939/HBASE-21934.branch-2.1.002.patch
 |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 16a6a8fd38ee 4.4.0-139-generic #165~14.04.1-Ubuntu SMP Wed Oct 
31 10:55:11 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 

[jira] [Commented] (HBASE-21917) Make the HFileBlock#validateChecksum can accept ByteBuff as an input.

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21917:


Results for branch HBASE-21917
[build #4 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21917/4/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21917/4//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21917/4//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21917/4//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21917/4//console].


> Make the HFileBlock#validateChecksum can accept ByteBuff as an input.
> -
>
> Key: HBASE-21917
> URL: https://issues.apache.org/jira/browse/HBASE-21917
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Attachments: HBASE-21917.v1.patch, HBASE-21917.v2.patch, 
> HBASE-21917.v3.patch, HBASE-21917.v4.patch
>
>
> I've tried to make a patch for HBASE-21879, most of work seems to be fine, 
> but the trouble is: 
> HFileBlock#validateChecksum can only accept ByteBuffer as its input, while 
> after the HBASE-21916, we will use an ourself-defined ByteBuff (which can be 
> SingleByteBuff or MultiByteBuff). 
> Now, need to create our own ByteBuff checksum validation method, should not 
> be so hard but an separate issue will be more clearer.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Comment Edited] (HBASE-20754) quickstart guide should instruct folks to set JAVA_HOME to a JDK installation.

2019-03-03 Thread Gokul (JIRA)


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

Gokul edited comment on HBASE-20754 at 3/4/19 3:23 AM:
---

[~busbey] If the update is okay, does this change have to be voted up to be 
committed? Could you please let me know if I've got to do something? I plan to 
look at other beginner issues after this one is committed. Thank you. 


was (Author: gokulsith):
[~busbey] If the update is okay, does this change have to be voted up to be 
committed? Could you please let me know if I've got to do something? I plan to 
look at other minor issues after this one is committed. Thank you. 

> quickstart guide should instruct folks to set JAVA_HOME to a JDK installation.
> --
>
> Key: HBASE-20754
> URL: https://issues.apache.org/jira/browse/HBASE-20754
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 3.0.0
>Reporter: Sean Busbey
>Assignee: Gokul
>Priority: Major
>  Labels: beginner
> Fix For: 3.0.0
>
> Attachments: HBASE-20754.master.001.patch, HBASE-20754.patch
>
>
> The quickstart guide currently instructs folks to set JAVA_HOME, but to the 
> wrong place
> {code}
> The JAVA_HOME variable should be set to a directory which contains the 
> executable file bin/java. Most modern Linux operating systems provide a 
> mechanism, such as /usr/bin/alternatives on RHEL or CentOS, for transparently 
> switching between versions of executables such as Java. In this case, you can 
> set JAVA_HOME to the directory containing the symbolic link to bin/java, 
> which is usually /usr.
> JAVA_HOME=/usr
> {code}
> instead, it should tell folks to point it to a jdk installation and help them 
> on how to find that.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21934) RemoteProcedureDispatcher should track the ongoing dispatched calls

2019-03-03 Thread Jingyun Tian (JIRA)


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

Jingyun Tian commented on HBASE-21934:
--

New patch is uploaded, failed tests all passed locally. Thanks [~Apache9] for 
help review.

> RemoteProcedureDispatcher should track the ongoing dispatched calls
> ---
>
> Key: HBASE-21934
> URL: https://issues.apache.org/jira/browse/HBASE-21934
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.x
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21934.branch-2.001.patch, 
> HBASE-21934.branch-2.1.001.patch, HBASE-21934.branch-2.1.001.patch, 
> HBASE-21934.branch-2.1.002.patch, HBASE-21934.branch-2.2.001.patch, 
> HBASE-21934.master.001.patch, HBASE-21934.master.002.patch, 
> HBASE-21934.master.003.patch, HBASE-21934.master.004.patch, 
> HBASE-21934.master.005.patch, HBASE-21934.master.006.patch, 
> HBASE-21934.master.007.patch, HBASE-21934.master.008.patch, 
> HBASE-21934.master.009.patch
>
>
> I encounter the problem that when master assign a splitWALRemoteProcedure to 
> a region server. The log of this region server says it failed to recover the 
> lease of this file. Then this region server is killed by chaosMonkey. As the 
> result, this procedure is not timeout and hang there forever.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (HBASE-21985) Set version as 2.1.4 in branch-2.1 in prep for first RC

2019-03-03 Thread Duo Zhang (JIRA)
Duo Zhang created HBASE-21985:
-

 Summary: Set version as 2.1.4 in branch-2.1 in prep for first RC
 Key: HBASE-21985
 URL: https://issues.apache.org/jira/browse/HBASE-21985
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (HBASE-21984) Generate CHANGES.md and RELEASENOTES.md for 2.1.4

2019-03-03 Thread Duo Zhang (JIRA)
Duo Zhang created HBASE-21984:
-

 Summary: Generate CHANGES.md and RELEASENOTES.md for 2.1.4
 Key: HBASE-21984
 URL: https://issues.apache.org/jira/browse/HBASE-21984
 Project: HBase
  Issue Type: Sub-task
Reporter: Duo Zhang






--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21934) RemoteProcedureDispatcher should track the ongoing dispatched calls

2019-03-03 Thread Jingyun Tian (JIRA)


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

Jingyun Tian updated HBASE-21934:
-
Attachment: HBASE-21934.branch-2.1.002.patch

> RemoteProcedureDispatcher should track the ongoing dispatched calls
> ---
>
> Key: HBASE-21934
> URL: https://issues.apache.org/jira/browse/HBASE-21934
> Project: HBase
>  Issue Type: Sub-task
>  Components: proc-v2
>Affects Versions: 2.x
>Reporter: Jingyun Tian
>Assignee: Jingyun Tian
>Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21934.branch-2.001.patch, 
> HBASE-21934.branch-2.1.001.patch, HBASE-21934.branch-2.1.001.patch, 
> HBASE-21934.branch-2.1.002.patch, HBASE-21934.branch-2.2.001.patch, 
> HBASE-21934.master.001.patch, HBASE-21934.master.002.patch, 
> HBASE-21934.master.003.patch, HBASE-21934.master.004.patch, 
> HBASE-21934.master.005.patch, HBASE-21934.master.006.patch, 
> HBASE-21934.master.007.patch, HBASE-21934.master.008.patch, 
> HBASE-21934.master.009.patch
>
>
> I encounter the problem that when master assign a splitWALRemoteProcedure to 
> a region server. The log of this region server says it failed to recover the 
> lease of this file. Then this region server is killed by chaosMonkey. As the 
> result, this procedure is not timeout and hang there forever.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21949) Fix flaky test TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts

2019-03-03 Thread Guanghao Zhang (JIRA)


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

Guanghao Zhang commented on HBASE-21949:


[~maoling] The problem I meet is not this... In my test PC, port  is binded 
by other services, so it catch BindException and use 8889 as the port. I 
thought we should assertTrue(clientPortList3[i] >= 
clientPortListInCluster.get(i).intValue()) here?

> Fix flaky test 
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts
> ---
>
> Key: HBASE-21949
> URL: https://issues.apache.org/jira/browse/HBASE-21949
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: maoling
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21949-branch-2.2.patch
>
>
> Found this when run ut for branch-2.2. It is easy to port conflict.
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts:299 
> expected:<8889> but was:<>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21949) Fix flaky test TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts

2019-03-03 Thread stack (JIRA)


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

stack commented on HBASE-21949:
---

LGTM

> Fix flaky test 
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts
> ---
>
> Key: HBASE-21949
> URL: https://issues.apache.org/jira/browse/HBASE-21949
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: maoling
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21949-branch-2.2.patch
>
>
> Found this when run ut for branch-2.2. It is easy to port conflict.
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts:299 
> expected:<8889> but was:<>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21512:


Results for branch HBASE-21512
[build #123 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/123/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/123//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/123//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/123//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/123//console].


> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need 
> to set a delay and use a thread pool any more, which could reduce the 
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely, 
> and start to rewrite the old sync client based on the async client, which 
> could reduce the code base a lot for our client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21983:


Results for branch master
[build #837 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/master/837/]: (x) 
*{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/837//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/837//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/master/837//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/master/837//console].


> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21983:


Results for branch branch-2
[build #1725 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1725/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1725//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1725//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1725//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2/1725//console].


> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21983:


Results for branch branch-2.2
[build #80 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/80/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/80//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/80//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.2/80//JDK8_Nightly_Build_Report_(Hadoop3)/]


(/) {color:green}+1 source release artifact{color}
-- See build output for details.


(/) {color:green}+1 client integration test{color}


> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21983:


Results for branch branch-2.1
[build #914 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/914/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/914//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/914//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/914//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/branch-2.1/914//console].


> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21935) Replace make_rc.sh with customized spark/dev/create-release

2019-03-03 Thread stack (JIRA)


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

stack commented on HBASE-21935:
---

.007 some fixes that come of testing: yetus needs python date package; change 
how we do the yetus untar.

> Replace make_rc.sh with customized spark/dev/create-release
> ---
>
> Key: HBASE-21935
> URL: https://issues.apache.org/jira/browse/HBASE-21935
> Project: HBase
>  Issue Type: Task
>  Components: rm
>Reporter: stack
>Assignee: stack
>Priority: Minor
>  Labels: rm
> Attachments: HBASE-21935.branch-2.1.001.patch, 
> HBASE-21935.branch-2.1.002.patch, HBASE-21935.branch-2.1.003.patch, 
> HBASE-21935.branch-2.1.004.patch, HBASE-21935.branch-2.1.005.patch, 
> HBASE-21935.branch-2.1.006.patch, HBASE-21935.branch-2.1.007.patch
>
>
> The spark/dev/create-release is more comprehensive than our hokey make_rc.sh 
> script. It codifies the bulk of the RM process from tagging, version-setting, 
> building, signing, and pushing. It does it in a container so environment is 
> same each time. It has a bunch of spark-specifics as is -- naturally -- but 
> should be possible to pull it around to suit hbase RM'ing. It'd save a bunch 
> of time and would allow us to get to a place where RM'ing is canned, 
> evolvable, and consistent.
> I've been hacking on the tooling before the filing of this JIRA and was 
> polluting branch-2.0 w/ tagging and reverts. Let me make a branch named for 
> this JIRA to play with (There is a dry-run flag but it too needs work...).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21935) Replace make_rc.sh with customized spark/dev/create-release

2019-03-03 Thread stack (JIRA)


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

stack updated HBASE-21935:
--
Attachment: HBASE-21935.branch-2.1.007.patch

> Replace make_rc.sh with customized spark/dev/create-release
> ---
>
> Key: HBASE-21935
> URL: https://issues.apache.org/jira/browse/HBASE-21935
> Project: HBase
>  Issue Type: Task
>  Components: rm
>Reporter: stack
>Assignee: stack
>Priority: Minor
>  Labels: rm
> Attachments: HBASE-21935.branch-2.1.001.patch, 
> HBASE-21935.branch-2.1.002.patch, HBASE-21935.branch-2.1.003.patch, 
> HBASE-21935.branch-2.1.004.patch, HBASE-21935.branch-2.1.005.patch, 
> HBASE-21935.branch-2.1.006.patch, HBASE-21935.branch-2.1.007.patch
>
>
> The spark/dev/create-release is more comprehensive than our hokey make_rc.sh 
> script. It codifies the bulk of the RM process from tagging, version-setting, 
> building, signing, and pushing. It does it in a container so environment is 
> same each time. It has a bunch of spark-specifics as is -- naturally -- but 
> should be possible to pull it around to suit hbase RM'ing. It'd save a bunch 
> of time and would allow us to get to a place where RM'ing is canned, 
> evolvable, and consistent.
> I've been hacking on the tooling before the filing of this JIRA and was 
> polluting branch-2.0 w/ tagging and reverts. Let me make a branch named for 
> this JIRA to play with (There is a dry-run flag but it too needs work...).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21949) Fix flaky test TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts

2019-03-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-21949:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
14s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} branch-2.2 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
14s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
14s{color} | {color:green} branch-2.2 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
36s{color} | {color:green} branch-2.2 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
28s{color} | {color:green} branch-2.2 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
18s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  2m 
33s{color} | {color:blue} hbase-server in branch-2.2 has 1 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
46s{color} | {color:green} branch-2.2 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
15s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 2s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  2m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  2m 
18s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  1m 
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 9s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 19s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  2m 
51s{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:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  0m 
43s{color} | {color:green} hbase-zookeeper in the patch passed. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green}128m  
2s{color} | {color:green} hbase-server in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
43s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black}171m 11s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:42ca976 |
| JIRA Issue | HBASE-21949 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12960915/HBASE-21949-branch-2.2.patch
 |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux a1ac70d3f0ec 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct 
5 08:56:16 UTC 2018 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | branch-2.2 / 9c5b0609a8 |
| maven | version: Apache Maven 3.5.4 

[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-21717:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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 83 new or modified test 
files. {color} |
|| || || || {color:brown} HBASE-21512 Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
25s{color} | {color:blue} Maven dependency ordering for branch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
59s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
49s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  3m 
21s{color} | {color:green} HBASE-21512 passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
16s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  2m 
21s{color} | {color:blue} hbase-server in HBASE-21512 has 1 extant Findbugs 
warnings. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m 
40s{color} | {color:blue} hbase-rest in HBASE-21512 has 2 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  1m 
54s{color} | {color:green} HBASE-21512 passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
53s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  4m 
49s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  0m 40s{color} 
| {color:red} hbase-client generated 6 new + 85 unchanged - 6 fixed = 91 total 
(was 91) {color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red}  1m 52s{color} 
| {color:red} hbase-server generated 1 new + 187 unchanged - 1 fixed = 188 
total (was 188) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
35s{color} | {color:red} hbase-client: The patch generated 1 new + 189 
unchanged - 32 fixed = 190 total (was 221) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  1m 
25s{color} | {color:red} hbase-server: The patch generated 7 new + 859 
unchanged - 81 fixed = 866 total (was 940) {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
19s{color} | {color:green} The patch passed checkstyle in hbase-mapreduce 
{color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
29s{color} | {color:green} The patch passed checkstyle in hbase-thrift {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
15s{color} | {color:green} hbase-backup: The patch generated 0 new + 0 
unchanged - 1 fixed = 0 total (was 1) {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  0m 
17s{color} | {color:red} hbase-rest: The patch generated 1 new + 77 unchanged - 
59 fixed = 78 total (was 136) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
12s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m  1s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  7m 
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  2m  
6s{color} | {color:green} the 

[jira] [Commented] (HBASE-21512) Introduce an AsyncClusterConnection and replace the usage of ClusterConnection

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21512:


Results for branch HBASE-21512
[build #122 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/122/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/122//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/122//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/122//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21512/122//console].


> Introduce an AsyncClusterConnection and replace the usage of ClusterConnection
> --
>
> Key: HBASE-21512
> URL: https://issues.apache.org/jira/browse/HBASE-21512
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
> Fix For: 3.0.0
>
>
> At least for the RSProcedureDispatcher, with CompletableFuture we do not need 
> to set a delay and use a thread pool any more, which could reduce the 
> resource usage and also the latency.
> Once this is done, I think we can remove the ClusterConnection completely, 
> and start to rewrite the old sync client based on the async client, which 
> could reduce the code base a lot for our client.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21879) Read HFile's block to ByteBuffer directly instead of to byte for reducing young gc purpose

2019-03-03 Thread Hudson (JIRA)


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

Hudson commented on HBASE-21879:


Results for branch HBASE-21879
[build #11 on 
builds.a.o|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/11/]: 
(x) *{color:red}-1 overall{color}*

details (if available):

(x) {color:red}-1 general checks{color}
-- For more information [see general 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/11//General_Nightly_Build_Report/]




(x) {color:red}-1 jdk8 hadoop2 checks{color}
-- For more information [see jdk8 (hadoop2) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/11//JDK8_Nightly_Build_Report_(Hadoop2)/]


(x) {color:red}-1 jdk8 hadoop3 checks{color}
-- For more information [see jdk8 (hadoop3) 
report|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/11//JDK8_Nightly_Build_Report_(Hadoop3)/]


(x) {color:red}-1 source release artifact{color}
-- See build output for details.


(x) {color:red}-1 client integration test{color}
-- Something went wrong with this stage, [check relevant console 
output|https://builds.apache.org/job/HBase%20Nightly/job/HBASE-21879/11//console].


> Read HFile's block to ByteBuffer directly instead of to byte for reducing 
> young gc purpose
> --
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
>  Issue Type: Improvement
>Reporter: Zheng Hu
>Assignee: Zheng Hu
>Priority: Major
> Fix For: 3.0.0, 2.3.0
>
> Attachments: HBASE-21879.v1.patch, HBASE-21879.v1.patch, 
> QPS-latencies-before-HBASE-21879.png, gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal,  we have the following: 
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum, 
> boolean updateMetrics)
>  throws IOException {
>  // .
>   // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with 
> BBPool (offheap).
>   byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
>   int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
>   onDiskSizeWithHeader - preReadHeaderSize, true, offset + 
> preReadHeaderSize, pread);
>   if (headerBuf != null) {
> // ...
>   }
>   // ...
>  }
> {code}
> In the read path,  we still read the block from hfile to on-heap byte[], then 
> copy the on-heap byte[] to offheap bucket cache asynchronously,  and in my  
> 100% get performance test, I also observed some frequent young gc,  The 
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to 
> byte[] for reducing young gc purpose. we did not implement this before, 
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+ 
> has supported this now,  so we can fix this now. I think. 
> Will provide an patch and some perf-comparison for this. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21949) Fix flaky test TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts

2019-03-03 Thread maoling (JIRA)


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

maoling updated HBASE-21949:

Status: Patch Available  (was: Open)

> Fix flaky test 
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts
> ---
>
> Key: HBASE-21949
> URL: https://issues.apache.org/jira/browse/HBASE-21949
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: maoling
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21949-branch-2.2.patch
>
>
> Found this when run ut for branch-2.2. It is easy to port conflict.
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts:299 
> expected:<8889> but was:<>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21949) Fix flaky test TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts

2019-03-03 Thread maoling (JIRA)


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

maoling updated HBASE-21949:

Attachment: HBASE-21949-branch-2.2.patch

> Fix flaky test 
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts
> ---
>
> Key: HBASE-21949
> URL: https://issues.apache.org/jira/browse/HBASE-21949
> Project: HBase
>  Issue Type: Bug
>Reporter: Guanghao Zhang
>Assignee: maoling
>Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0
>
> Attachments: HBASE-21949-branch-2.2.patch
>
>
> Found this when run ut for branch-2.2. It is easy to port conflict.
> TestHBaseTestingUtility.testMiniZooKeeperWithMultipleClientPorts:299 
> expected:<8889> but was:<>



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21895) Take more care on the error prone plugin and warnings

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21895:
---

OK, seems not easy. I do not know why we use such a complicated way to 
integrate error prone...

If we want to add new checks, can we use a separated repo instead of doing this 
magic in the main hbase repo? What do you think sir [~apurtell]? Thanks...

> Take more care on the error prone plugin and warnings
> -
>
> Key: HBASE-21895
> URL: https://issues.apache.org/jira/browse/HBASE-21895
> Project: HBase
>  Issue Type: Umbrella
>Reporter: Duo Zhang
>Priority: Major
>
> As shown in HBASE-21890 , the error prone warnings are truly useful.
> But now, the javac warnings section in the pre commit result is messed up, it 
> always reports unrelated warnings. Need to take a look at it.
> And also, we should try out best to clean up the warnings.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21717:
---

Disabled two tests, TestScannerHeartbeatMessages and 
TestAvoidCellReferencesIntoShippedBlocks, as they can not work together with 
async prefetch scanner. For the heartbeat message, I plan to add UTs for async 
client to cover the cases in TestScannerHeartbeatMessages , and for 
TestAvoidCellReferencesIntoShippedBlocks, I think it will be gone after we 
address HBASE-21879 so...

> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch, 
> HBASE-21717-HBASE-21512-v2.patch, HBASE-21717-HBASE-21512-v3.patch, 
> HBASE-21717-HBASE-21512-v4.patch, HBASE-21717-HBASE-21512-v5.patch, 
> HBASE-21717-HBASE-21512-v6.patch, HBASE-21717-HBASE-21512.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21717) Implement Connection based on AsyncConnection

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang updated HBASE-21717:
--
Attachment: HBASE-21717-HBASE-21512-v6.patch

> Implement Connection based on AsyncConnection
> -
>
> Key: HBASE-21717
> URL: https://issues.apache.org/jira/browse/HBASE-21717
> Project: HBase
>  Issue Type: Sub-task
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
> Attachments: HBASE-21717-HBASE-21512-v1.patch, 
> HBASE-21717-HBASE-21512-v2.patch, HBASE-21717-HBASE-21512-v3.patch, 
> HBASE-21717-HBASE-21512-v4.patch, HBASE-21717-HBASE-21512-v5.patch, 
> HBASE-21717-HBASE-21512-v6.patch, HBASE-21717-HBASE-21512.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang updated HBASE-21983:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Pushed to branch-2.1+.

> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21874) Bucket cache on Persistent memory

2019-03-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-21874:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
13s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {color} ||
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green}  0m  
0s{color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green}  0m  
0s{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green}  0m 
 0s{color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
|| || || || {color:brown} master Compile Tests {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}  3m 
52s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  5m 
24s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  2m 
 2s{color} | {color:green} master passed {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue}  5m 
25s{color} | {color:blue} branch has no errors when building the reference 
guide. See footer for rendered docs, which you should manually inspect. {color} 
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
 8s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  0m  
0s{color} | {color:blue} Skipped patched modules with no Java source: . {color} 
|
| {color:blue}0{color} | {color:blue} findbugs {color} | {color:blue}  2m 
14s{color} | {color:blue} hbase-server in master has 1 extant Findbugs 
warnings. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  3m 
19s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:blue}0{color} | {color:blue} mvndep {color} | {color:blue}  0m 
13s{color} | {color:blue} Maven dependency ordering for patch {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  3m 
44s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  5m 
24s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  5m 
24s{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red}  2m  
4s{color} | {color:red} root: The patch generated 1 new + 32 unchanged - 1 
fixed = 33 total (was 33) {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green}  0m  
2s{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:blue}0{color} | {color:blue} refguide {color} | {color:blue}  4m 
56s{color} | {color:blue} patch has no errors when building the reference 
guide. See footer for rendered docs, which you should manually inspect. {color} 
|
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
10s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
7m 59s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {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}  3m 
16s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  3m 
26s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}198m 
32s{color} | {color:green} root in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  1m 
38s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | 

[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Hadoop QA (JIRA)


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

Hadoop QA commented on HBASE-21983:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue}  0m 
11s{color} | {color:blue} Docker mode activated. {color} |
|| || || || {color:brown} Prechecks {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:orange}-0{color} | {color:orange} test4tests {color} | {color:orange}  
0m  0s{color} | {color:orange} 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:brown} master Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
31s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
46s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
34s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
34s{color} | {color:green} branch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m  
2s{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
21s{color} | {color:green} master passed {color} |
|| || || || {color:brown} Patch Compile Tests {color} ||
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green}  4m 
 8s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green}  0m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green}  0m 
42s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green}  0m 
31s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green}  0m 
 0s{color} | {color:green} The patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} shadedjars {color} | {color:green}  4m 
36s{color} | {color:green} patch has no errors when building our shaded 
downstream artifacts. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green}  
8m 47s{color} | {color:green} Patch does not cause any errors with Hadoop 2.7.4 
or 3.0.0. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green}  1m 
11s{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green}  0m 
20s{color} | {color:green} the patch passed {color} |
|| || || || {color:brown} Other Tests {color} ||
| {color:green}+1{color} | {color:green} unit {color} | {color:green}  3m 
12s{color} | {color:green} hbase-client in the patch passed. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green}  0m 
 8s{color} | {color:green} The patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 35m 58s{color} | 
{color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=17.05.0-ce Server=17.05.0-ce Image:yetus/hbase:b002b0b |
| JIRA Issue | HBASE-21983 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12960909/HBASE-21983-v1.patch |
| Optional Tests |  dupname  asflicense  javac  javadoc  unit  findbugs  
shadedjars  hadoopcheck  hbaseanti  checkstyle  compile  |
| uname | Linux 88487bc9e76c 4.4.0-138-generic #164~14.04.1-Ubuntu SMP Fri Oct 
5 08:56:16 UTC 2018 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 / 7142cea121 |
| maven | version: Apache Maven 3.5.4 
(1edded0938998edf8bf061f1ceb3cfdeccf443fe; 2018-06-17T18:33:14Z) |
| Default Java | 1.8.0_181 |
| findbugs | v3.1.11 |
|  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/16217/testReport/ |
| Max. process+thread count | 267 (vs. ulimit of 1) |
| modules | C: hbase-client U: hbase-client |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/16217/console 

[jira] [Commented] (HBASE-21960) RESTServletContainer not configured for REST Jetty server

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21960:
---

But it seems that branch-2.0 is fine...

> RESTServletContainer not configured for REST Jetty server
> -
>
> Key: HBASE-21960
> URL: https://issues.apache.org/jira/browse/HBASE-21960
> Project: HBase
>  Issue Type: Bug
>  Components: REST
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.1.4
>
> Attachments: HBASE-21960.001.patch, HBASE-21960.002.patch, 
> HBASE-21960.003.patch, HBASE-21960.004.patch, HBASE-21960.005.patch
>
>
> The upgrade to Jetty 9 (HBASE-12894) appears to have missed including the 
> RESTServletContainer as the base servlet for Jetty. Make sure we configure 
> that class.
> I also have some testing to prevent a regression again in the future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21960) RESTServletContainer not configured for REST Jetty server

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21960:
---

Hey [~elserj] Seems something wrong with the hadoop3 compatibility?

https://builds.apache.org/job/HBase%20Nightly/job/master/835/testReport/junit/org.apache.hadoop.hbase.rest/TestSecureRESTServer/health_checks___yetus_jdk8_hadoop3_checks___org_apache_hadoop_hbase_rest_TestSecureRESTServer/

It says

{noformat}
java.lang.NoClassDefFoundError: org/bouncycastle/x509/X509V1CertificateGenerator
at 
org.apache.hadoop.hbase.rest.TestSecureRESTServer.setHdfsSecuredConfiguration(TestSecureRESTServer.java:282)
at 
org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:175)
Caused by: java.lang.ClassNotFoundException: 
org.bouncycastle.x509.X509V1CertificateGenerator
at 
org.apache.hadoop.hbase.rest.TestSecureRESTServer.setHdfsSecuredConfiguration(TestSecureRESTServer.java:282)
at 
org.apache.hadoop.hbase.rest.TestSecureRESTServer.setupServer(TestSecureRESTServer.java:175)
{noformat}

> RESTServletContainer not configured for REST Jetty server
> -
>
> Key: HBASE-21960
> URL: https://issues.apache.org/jira/browse/HBASE-21960
> Project: HBase
>  Issue Type: Bug
>  Components: REST
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Blocker
> Fix For: 3.0.0, 2.2.0, 2.0.5, 2.1.4
>
> Attachments: HBASE-21960.001.patch, HBASE-21960.002.patch, 
> HBASE-21960.003.patch, HBASE-21960.004.patch, HBASE-21960.005.patch
>
>
> The upgrade to Jetty 9 (HBASE-12894) appears to have missed including the 
> RESTServletContainer as the base servlet for Jetty. Make sure we configure 
> that class.
> I also have some testing to prevent a regression again in the future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang commented on HBASE-21983:
---

Do not need to track metrics when calling renewLease, as we do not process the 
response...

> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (HBASE-21983) Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if scan metrics is enabled

2019-03-03 Thread Duo Zhang (JIRA)


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

Duo Zhang updated HBASE-21983:
--
Attachment: HBASE-21983-v1.patch

> Should track the scan metrics in AsyncScanSingleRegionRpcRetryingCaller if 
> scan metrics is enabled
> --
>
> Key: HBASE-21983
> URL: https://issues.apache.org/jira/browse/HBASE-21983
> Project: HBase
>  Issue Type: Bug
>  Components: asyncclient, Client
>Reporter: Duo Zhang
>Assignee: Duo Zhang
>Priority: Major
>  Labels: trivial
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21983-v1.patch, HBASE-21983.patch
>
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)