[jira] [Updated] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles

[Appy (JIRA)]

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

Appy updated HBASE-15236:
-
Description: 
 If there are two bulkloaded hfiles in a region with same seqID, same 
timestamps and duplicate keys*, get and scan may return different values for a 
key. Not sure how this would happen, but one of our customer uploaded a dataset 
with 2 files in a single region and both having same bulk load timestamp. These 
files are small ~50M (I couldn't find any setting for max file size that could 
lead to 2 files). The range of keys in two hfiles are overlapping to some 
extent, but not fully (so the two files are because of region merge).
In such a case, depending on file sizes (used in StoreFile.Comparators.SEQ_ID), 
we may get different values for the same cell (say "r", "cf:50") depending on 
what we call: get "r" "cf:50" or get "r" "cf:".
To replicate this, i ran ImportTsv twice with 2 different csv files but same 
timestamp (-Dimporttsv.timestamp=1). Collected two resulting hfiles in a single 
directory and loaded with LoadIncrementalHFiles. Here are the commands.
{noformat}
//CSV files should be in hdfs://user/hbase/tmp
sudo -u hbase hbase org.apache.hadoop.hbase.mapreduce.ImportTsv  
-Dimporttsv.columns=HBASE_ROW_KEY,c:1,c:2,c:3,c:4,c:5,c:6 
-Dimporttsv.separator='|' -Dimporttsv.timestamp=1 t tmp
// Copied hfiles to /tmp/1 dir, then loaded them.
hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles  /tmp/1 t
{noformat}

To load these hfiles (attached) as a region and test with them, attaching a 
small piece of code, TestWithSingleHRegion.java. (Change ROOT_DIR appropriately)
Hfiles:
1) 07922ac90208445883b2ddc89c424c89 : length = 1094: KVs = (c:5, 55) (c:6, 66)
2) 143137fa4fa84625b4e8d1d84a494f08 : length = 1192: KVs = (c:1, 1) (c:2, 2) 
(c:3, 3) (c:4, 4) (c:5, 5) (c:6, 6)

Get returns 5  where as Scan returns 55.

On the other hand if I make the first hfile, the one with values 55 and 66 
bigger in size than second hfile, then:
Get returns 55  where as Scan returns 55.

Weird things:
1. Get consistently returns values from larger hfile.
2. Scan consistently returns 55.

Reason:
Explanation 1: We add StoreFileScanners to heap by iterating over list of store 
files which is kept sorted in DefaultStoreFileManger using 
StoreFile.Comparators.SEQ_ID. It sorts the file first by increasing seq id, 
then by decreasing filesize. So our larger files sizes are always in the start.

Explanation 2: In KeyValueHeap.next(), if both current and this.heap.peek() 
scanners (type is StoreFileScanner in this case) point to KVs which compare as 
equal, we put back the current scanner into heap, and call pollRealKV() to get 
new one. While inserting, KVScannerComparator is used which compares the two 
(one already in heap and the one being inserted) as equal and inserts it after 
the existing one. \[1\]
Say s1 is scanner over first hfile and s2 over second.
1. We scan with s2 to get values 1, 2, 3, 4
2. see that both scanners have c:5 as next key, put current scanner s2 back in 
heap, take s1 out
4. return 55, advance s1 to key c:6
5. compare c:6 to c:5, put back s2 in heap since it has larger key, take out s1
6. ignore it's value (there is code for that too), advance s2 to c:6
Go back to step 2 with both scanners having c:6 as next key

This is wrong because if we add a key between c:4 and c:5 to first hfile, say 
(c:44, foo)  which makes s1 as the 'current' scanner when we hit step 2, then 
we'll get the values - 1, 2, 3, 4, foo, 5, 6.

Fix:
Assign priority ids to StoreFileScanners when inserting them into heap, latest 
hfiles get higher priority, and use them in KVComparator instead of just seq id.

\[1\] 
[PriorityQueue.siftUp()|http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/java/util/PriorityQueue.java#586]

  was:
If there are two bulkloaded hfiles in a region with same seqID, same timestamps 
and duplicate keys*, get and scan may return different values for a key. Not 
sure how this would happen, but one of our customer uploaded a dataset with 2 
files in a single region and both having same bulk load timestamp. These files 
are small ~50M (I couldn't find any setting for max file size that could lead 
to 2 files). The range of keys in two hfiles are overlapping to some extent, 
but not fully (so the two files are because of region merge).
In such a case, depending on file sizes (because we take it into account when 
sorting hfiles internally), we may get different values for the same cell (say 
"r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" "cf:".

I have been able to replicate this issue, will post the instructions shortly.

---
\* 


> Inconsistent cell reads over multiple bulk-loaded HFiles
> 
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
>  

[jira] [Commented] (HBASE-14735) Region may grow too big and can not be split

[Shuaifeng Zhou (JIRA)]

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

Shuaifeng Zhou commented on HBASE-14735:


In our clusters fixed like this, and this problem never happened again during 
the passed few monthes.

> Region may grow too big and can not be split
> 
>
> Key: HBASE-14735
> URL: https://issues.apache.org/jira/browse/HBASE-14735
> Project: HBase
>  Issue Type: Bug
>  Components: Compaction, regionserver
>Affects Versions: 1.1.2, 0.98.15
>Reporter: Shuaifeng Zhou
>Assignee: Shuaifeng Zhou
> Attachments: 14735-0.98.patch, 14735-branch-1.1.patch, 
> 14735-branch-1.2.patch, 14735-branch-1.2.patch, 14735-master (2).patch, 
> 14735-master.patch, 14735-master.patch
>
>
> When a compaction completed, may there are also many storefiles in the store, 
> and CompactPriority < 0, then compactSplitThread will do a "Recursive 
> enqueue" compaction request instead of request a split:
> {code:title=CompactSplitThread.java|borderStyle=solid}
> if (completed) {
>   // degenerate case: blocked regions require recursive enqueues
>   if (store.getCompactPriority() <= 0) {
> requestSystemCompaction(region, store, "Recursive enqueue");
>   } else {
> // see if the compaction has caused us to exceed max region size
> requestSplit(region);
>   }
> {code}
> But in some situation, the "recursive enqueue" request may return null, and 
> not build up a new compaction runner. For example, an other compaction of the 
> same region is running, and compaction selection will exclude all files older 
> than the newest files currently compacting, this may cause no enough files 
> can be selected by the "recursive enqueue" request. When this happen, split 
> will not be trigged. If the input load is high enough, compactions aways 
> running on the region, and split will never be triggered.
> In our cluster, this situation happened, and a huge region more than 400GB 
> and 100+ storefiles appeared. Version is 0.98.10, and the trank also have the 
> problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-11927) Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to CRC32C)

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-11927:

Fix Version/s: (was: 1.1.4)

> Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to 
> CRC32C)
> 
>
> Key: HBASE-11927
> URL: https://issues.apache.org/jira/browse/HBASE-11927
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance
>Reporter: stack
>Assignee: Appy
> Fix For: 2.0.0, 1.2.0
>
> Attachments: HBASE-11927-branch-1.1.patch, HBASE-11927-v1.patch, 
> HBASE-11927-v2.patch, HBASE-11927-v4.patch, HBASE-11927-v5.patch, 
> HBASE-11927-v6.patch, HBASE-11927-v7.patch, HBASE-11927-v8.patch, 
> HBASE-11927-v8.patch, HBASE-11927.patch, after-compact-2%.svg, 
> after-randomWrite1M-0.5%.svg, before-compact-22%.svg, 
> before-randomWrite1M-5%.svg, c2021.crc2.svg, c2021.write.2.svg, 
> c2021.zip.svg, crc32ct.svg
>
>
> Up in hadoop they have this change. Let me publish some graphs to show that 
> it makes a difference (CRC is a massive amount of our CPU usage in my 
> profiling of an upload because of compacting, flushing, etc.).  We should 
> also make use of native CRCings -- especially the 2.6 HDFS-6865 and ilk -- in 
> hbase but that is another issue for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property

[Hudson (JIRA)]

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

Hudson commented on HBASE-15247:


FAILURE: Integrated in HBase-Trunk_matrix #728 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/728/])
HBASE-15247 InclusiveStopFilter does not respect reverse Filter (anoopsamjohn: 
rev 2d66cd86d08120887efe05b65fa53bd667a5be76)
* hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilter.java
* 
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/InclusiveStopFilter.java


> InclusiveStopFilter does not respect reverse Filter property
> 
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter 
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed 
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-11927) Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to CRC32C)

[stack (JIRA)]

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

stack updated HBASE-11927:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

Re-resolving. I'd say time for new JIRA if you fellas pulling it back.

> Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to 
> CRC32C)
> 
>
> Key: HBASE-11927
> URL: https://issues.apache.org/jira/browse/HBASE-11927
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance
>Reporter: stack
>Assignee: Appy
> Fix For: 2.0.0, 1.1.4, 1.2.0
>
> Attachments: HBASE-11927-branch-1.1.patch, HBASE-11927-v1.patch, 
> HBASE-11927-v2.patch, HBASE-11927-v4.patch, HBASE-11927-v5.patch, 
> HBASE-11927-v6.patch, HBASE-11927-v7.patch, HBASE-11927-v8.patch, 
> HBASE-11927-v8.patch, HBASE-11927.patch, after-compact-2%.svg, 
> after-randomWrite1M-0.5%.svg, before-compact-22%.svg, 
> before-randomWrite1M-5%.svg, c2021.crc2.svg, c2021.write.2.svg, 
> c2021.zip.svg, crc32ct.svg
>
>
> Up in hadoop they have this change. Let me publish some graphs to show that 
> it makes a difference (CRC is a massive amount of our CPU usage in my 
> profiling of an upload because of compacting, flushing, etc.).  We should 
> also make use of native CRCings -- especially the 2.6 HDFS-6865 and ilk -- in 
> hbase but that is another issue for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15310:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s 
{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
22s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 58s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 15s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
12s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 59s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 59s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 10s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
19s {color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} whitespace {color} | {color:red} 0m 1s 
{color} | {color:red} The patch has 16 line(s) with tabs. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 0s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
28m 20s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 14s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 16s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 9s 
{color} | {color:green} hbase-spark in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 35s 
{color} | {color:green} hbase-spark in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
11s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 42m 10s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-23 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12789140/hbase-15310.patch |
| JIRA Issue | HBASE-15310 |
| Optional Tests |  asflicense  javac  javadoc  unit  xml  compile  |
| uname | Linux 56b47305b1f0 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed 
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / a8073c4 |
| whitespace | 
https://builds.apache.org/job/PreCommit-HBASE-Build/645/artifact/patchprocess/whitespace-tabs.txt
 |
| JDK v1.7.0_95  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/645/testReport/ |
| modules | C: hbase-spark U: hbase-spark |
| Max memory used | 187MB |
| Powered by | Apache Yetus 0.1.0   http://yetus.apache.org |

[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream

[stack (JIRA)]

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

stack commented on HBASE-15264:
---

[~Apache9] This patch is four new classes that do not touch any other code. 
Could go into master. I think it would be better if the whole working fanout 
WAL provider came in as a 'finished' lump so suggest putting these classes on a 
'FanOutWAL' branch and then fill in the other necessary pieces around it. When 
all running, all current WAL tests with this provider in place are passing, we 
can pull into master branch.

But do what is easier on you making progress (master or branch).

I'm game for testing whenever you ready.

On the patch, ok on having the classes in util for reasons above (on commit, 
add comment on why core i/o classes are off in a util package...).

That is a fat bunch of params to pass the constructor:

312   FanOutOneBlockAsyncDFSOutput(Configuration conf, FSUtils fsUtils, 
DistributedFileSystem dfs,
313   DFSClient client, ClientProtocol namenode, String clientName, 
String src, long fileId,
314   LocatedBlock locatedBlock, EventLoop eventLoop, List 
datanodeList,
315   DataChecksum summer, ByteBufAllocator alloc) {

Thats how DFSOS takes params? Can't do builder because all params are needed?

FanOutOneBlockAsyncDFSOutput is clean, easy enough to follow what is going on 
(I think -- smile -- if I can remember my netty-ese). The helper needs a bit of 
commentary. You know how it all works at the moment. Would be good to get some 
doc in there while fresh in your mind. Like how DFS_CLIENT_ADAPTOR works and 
LeaseManager (Sorry you have to do all this reflection stuff but you have it 
nicely contained)... even if it was just a note on why you have to do these 
gymnastics and the basic technique you have employed.

What did we say about this:

ByteBuf checksumBuf = alloc.directBuffer(checksumLen);

That we are allocating offheap. when writing always  The offheap 
allocations are relatively slow... Can use a pool later?

... and here: ByteBuf newBuf = 
alloc.directBuffer().ensureWritable(trailingPartialChunkLen);

Tests look good -- yeah, the create w/o create of parent is needed for the 
fencing trick.

This looks great [~Apache9]









> Implement a fan out HDFS OutputStream
> -
>
> Key: HBASE-15264
> URL: https://issues.apache.org/jira/browse/HBASE-15264
> Project: HBase
>  Issue Type: Sub-task
>  Components: util, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, 
> HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, 
> HBASE-15264-v6.patch, HBASE-15264.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property

[Hudson (JIRA)]

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

Hudson commented on HBASE-15247:


SUCCESS: Integrated in HBase-1.3-IT #510 (See 
[https://builds.apache.org/job/HBase-1.3-IT/510/])
HBASE-15247 InclusiveStopFilter does not respect reverse Filter (anoopsamjohn: 
rev cc45b4ab38edee680a4356d3f57437d12a55de24)
* 
hbase-client/src/main/java/org/apache/hadoop/hbase/filter/InclusiveStopFilter.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/filter/TestFilter.java


> InclusiveStopFilter does not respect reverse Filter property
> 
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter 
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed 
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-15205:
---
Status: Patch Available  (was: Open)

> Do not find the replication scope for every WAL#append()
> 
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch, 
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch, 
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch, 
> HBASE-15205_7.patch, ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though 
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication 
> scope associate with the families associated with the TableDescriptor. I 
> think per WAL append doing this is very costly and creates lot of garbage. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-15205:
---
Attachment: HBASE-15205_7.patch

bq.FSWALEntry still has replicationScope. That intentional? I thought only 
WALKey was going to have scopes?
Yes Stack as said in my earlier comments I was not able to directly pass it to 
WALKey on construction. Hence using the replicationScope in FSWAlEntry to be 
passed directly to HLog.append() and use that scope to be set on the WALKey.
Corrected the failing testcase. Patch for QA before commit.

> Do not find the replication scope for every WAL#append()
> 
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch, 
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch, 
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch, 
> HBASE-15205_7.patch, ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though 
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication 
> scope associate with the families associated with the TableDescriptor. I 
> think per WAL append doing this is very costly and creates lot of garbage. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15205) Do not find the replication scope for every WAL#append()

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-15205:
---
Status: Open  (was: Patch Available)

> Do not find the replication scope for every WAL#append()
> 
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch, 
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch, 
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch, 
> ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though 
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication 
> scope associate with the families associated with the TableDescriptor. I 
> think per WAL append doing this is very costly and creates lot of garbage. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14932) bulkload fails because file not found

[Shuaifeng Zhou (JIRA)]

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

Shuaifeng Zhou updated HBASE-14932:
---
Attachment: HBASE-14932-0.98.patch

A solution is when HRegion bulkLoadHFiles, ignore FileNotFoundException to 
continue.
Patch on 0.98 is attached, please review it

> bulkload fails because file not found
> -
>
> Key: HBASE-14932
> URL: https://issues.apache.org/jira/browse/HBASE-14932
> Project: HBase
>  Issue Type: Bug
>  Components: regionserver
>Affects Versions: 0.98.10
>Reporter: Shuaifeng Zhou
>Assignee: Alicia Ying Shu
> Fix For: 0.98.18
>
> Attachments: HBASE-14932-0.98.patch
>
>
> When make a dobulkload call, one call may contain sevel hfiles to load, but 
> the call may timeout during regionserver load files, and client will retry to 
> load.
> But when client doing retry call, regionserver may continue doing load 
> operation, if somefiles success, the retry call will throw filenotfound 
> exception, and this will cause client retry again and again until retry 
> exhausted, and bulkload fails.
> When this happening, actually, some files are loaded successfully, that's a 
> inconsistent status.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-13259) mmap() based BucketCache IOEngine

[stack (JIRA)]

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

stack commented on HBASE-13259:
---

+1 if hadoopqa is good w/ it. Mind adding a release note [~ram_krish] Thats 
great you carried this one home.

> mmap() based BucketCache IOEngine
> -
>
> Key: HBASE-13259
> URL: https://issues.apache.org/jira/browse/HBASE-13259
> Project: HBase
>  Issue Type: New Feature
>  Components: BlockCache
>Affects Versions: 0.98.10
>Reporter: Zee Chen
>Assignee: Zee Chen
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13259-v2.patch, HBASE-13259.patch, 
> HBASE-13259_v3.patch, HBASE-13259_v4.patch, HBASE-13259_v5.patch, 
> ioread-1.svg, mmap-0.98-v1.patch, mmap-1.svg, mmap-trunk-v1.patch
>
>
> Of the existing BucketCache IOEngines, FileIOEngine uses pread() to copy data 
> from kernel space to user space. This is a good choice when the total working 
> set size is much bigger than the available RAM and the latency is dominated 
> by IO access. However, when the entire working set is small enough to fit in 
> the RAM, using mmap() (and subsequent memcpy()) to move data from kernel 
> space to user space is faster. I have run some short keyval gets tests and 
> the results indicate a reduction of 2%-7% of kernel CPU on my system, 
> depending on the load. On the gets, the latency histograms from mmap() are 
> identical to those from pread(), but peak throughput is close to 40% higher.
> This patch modifies ByteByfferArray to allow it to specify a backing file.
> Example for using this feature: set  hbase.bucketcache.ioengine to 
> mmap:/dev/shm/bucketcache.0 in hbase-site.xml.
> Attached perf measured CPU usage breakdown in flames graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

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

Jonathan Hsieh commented on HBASE-15310:


v1: Was able to get past compilation problem and have a clover run actually 
start exectuing tests. 

> hbase-spark module has compilation failures with clover profile
> ---
>
> Key: HBASE-15310
> URL: https://issues.apache.org/jira/browse/HBASE-15310
> Project: HBase
>  Issue Type: Bug
>  Components: spark, test
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0
>
> Attachments: hbase-15310.patch
>
>
> running with a clover profile enabled will fail due to cross compilation 
> ordering issues with the hbase-spark module.  
> {code}
> 21:07:47 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project hbase-spark: Compilation failure: Compilation 
> failure:
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
>  error: cannot find symbol
> 21:07:47 [ERROR] symbol:   class JavaHBaseContext
> 21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
>  error: cannot find symbol
>  (many classes)
> {code}
> Apparently this is a known issue and this page shows a remedy.
>  
> https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property

[Rick Moritz (JIRA)]

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

Rick Moritz commented on HBASE-15247:
-

Thanks for the quick fix, Amal!

> InclusiveStopFilter does not respect reverse Filter property
> 
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter 
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed 
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

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

Work on HBASE-15310 started by Jonathan Hsieh.
--
> hbase-spark module has compilation failures with clover profile
> ---
>
> Key: HBASE-15310
> URL: https://issues.apache.org/jira/browse/HBASE-15310
> Project: HBase
>  Issue Type: Bug
>  Components: spark, test
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0
>
> Attachments: hbase-15310.patch
>
>
> running with a clover profile enabled will fail due to cross compilation 
> ordering issues with the hbase-spark module.  
> {code}
> 21:07:47 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project hbase-spark: Compilation failure: Compilation 
> failure:
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
>  error: cannot find symbol
> 21:07:47 [ERROR] symbol:   class JavaHBaseContext
> 21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
>  error: cannot find symbol
>  (many classes)
> {code}
> Apparently this is a known issue and this page shows a remedy.
>  
> https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

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

Jonathan Hsieh updated HBASE-15310:
---
Attachment: hbase-15310.patch

> hbase-spark module has compilation failures with clover profile
> ---
>
> Key: HBASE-15310
> URL: https://issues.apache.org/jira/browse/HBASE-15310
> Project: HBase
>  Issue Type: Bug
>  Components: spark, test
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0
>
> Attachments: hbase-15310.patch
>
>
> running with a clover profile enabled will fail due to cross compilation 
> ordering issues with the hbase-spark module.  
> {code}
> 21:07:47 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project hbase-spark: Compilation failure: Compilation 
> failure:
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
>  error: cannot find symbol
> 21:07:47 [ERROR] symbol:   class JavaHBaseContext
> 21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
>  error: cannot find symbol
>  (many classes)
> {code}
> Apparently this is a known issue and this page shows a remedy.
>  
> https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

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

Jonathan Hsieh updated HBASE-15310:
---
Status: Patch Available  (was: In Progress)

> hbase-spark module has compilation failures with clover profile
> ---
>
> Key: HBASE-15310
> URL: https://issues.apache.org/jira/browse/HBASE-15310
> Project: HBase
>  Issue Type: Bug
>  Components: spark, test
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0
>
> Attachments: hbase-15310.patch
>
>
> running with a clover profile enabled will fail due to cross compilation 
> ordering issues with the hbase-spark module.  
> {code}
> 21:07:47 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project hbase-spark: Compilation failure: Compilation 
> failure:
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
>  error: cannot find symbol
> 21:07:47 [ERROR] symbol:   class JavaHBaseContext
> 21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
>  error: cannot find symbol
>  (many classes)
> {code}
> Apparently this is a known issue and this page shows a remedy.
>  
> https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15205) Do not find the replication scope for every WAL#append()

[stack (JIRA)]

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

stack commented on HBASE-15205:
---

FSWALEntry still has replicationScope. That intentional? I thought only WALKey 
was going to have scopes?

On commit, change the variable name to replicationScope as you have it 
elsewhere in WALUtil

final NavigableMap scope

Otherwise, +1









> Do not find the replication scope for every WAL#append()
> 
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch, 
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch, 
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch, 
> ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though 
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication 
> scope associate with the families associated with the TableDescriptor. I 
> think per WAL append doing this is very costly and creates lot of garbage. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

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

Jonathan Hsieh updated HBASE-15310:
---
Description: 
running with a clover profile enabled will fail due to cross compilation 
ordering issues with the hbase-spark module.  

{code}
21:07:47 [ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile (default-compile) 
on project hbase-spark: Compilation failure: Compilation failure:
21:07:47 [ERROR] 
/data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
 error: cannot find symbol
21:07:47 [ERROR] symbol:   class JavaHBaseContext
21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
21:07:47 [ERROR] 
/data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
 error: cannot find symbol
 (many classes)
{code}
Apparently this is a known issue and this page shows a remedy.

 
https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol

  was:
running with a clover profile enabled will fail due to cross compilation 
ordering issues with the hbase-spark module.  

Apparently this is a known issue and this page shows a remedy.

 
https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol


> hbase-spark module has compilation failures with clover profile
> ---
>
> Key: HBASE-15310
> URL: https://issues.apache.org/jira/browse/HBASE-15310
> Project: HBase
>  Issue Type: Bug
>  Components: spark, test
>Affects Versions: 2.0.0
>Reporter: Jonathan Hsieh
>Assignee: Jonathan Hsieh
> Fix For: 2.0.0
>
>
> running with a clover profile enabled will fail due to cross compilation 
> ordering issues with the hbase-spark module.  
> {code}
> 21:07:47 [ERROR] Failed to execute goal 
> org.apache.maven.plugins:maven-compiler-plugin:2.5.1:compile 
> (default-compile) on project hbase-spark: Compilation failure: Compilation 
> failure:
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseBulkDeleteExample.java:[23,36]
>  error: cannot find symbol
> 21:07:47 [ERROR] symbol:   class JavaHBaseContext
> 21:07:47 [ERROR] location: package org.apache.hadoop.hbase.spark
> 21:07:47 [ERROR] 
> /data/jenkins/workspace/CDH5.7.0-HBase-1.2.0-Clover/hbase-spark/target/clover/src-instrumented/org/apache/hadoop/hbase/spark/example/hbasecontext/JavaHBaseDistributedScan.java:[27,36]
>  error: cannot find symbol
>  (many classes)
> {code}
> Apparently this is a known issue and this page shows a remedy.
>  
> https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15310) hbase-spark module has compilation failures with clover profile

[Jonathan Hsieh (JIRA)]

Jonathan Hsieh created HBASE-15310:
--

 Summary: hbase-spark module has compilation failures with clover 
profile
 Key: HBASE-15310
 URL: https://issues.apache.org/jira/browse/HBASE-15310
 Project: HBase
  Issue Type: Bug
  Components: spark, test
Affects Versions: 2.0.0
Reporter: Jonathan Hsieh
Assignee: Jonathan Hsieh
 Fix For: 2.0.0


running with a clover profile enabled will fail due to cross compilation 
ordering issues with the hbase-spark module.  

Apparently this is a known issue and this page shows a remedy.

 
https://confluence.atlassian.com/display/CLOVERKB/Java-+Scala+cross-compilation+error+-+cannot+find+symbol



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15309) GZIP HFile Compression & Decompression Memory Leak, Similar Issue HBASE-5516

[karthikp (JIRA)]

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

karthikp updated HBASE-15309:
-
Assignee: Ted Yu

> GZIP HFile Compression & Decompression Memory Leak, Similar Issue HBASE-5516
> 
>
> Key: HBASE-15309
> URL: https://issues.apache.org/jira/browse/HBASE-15309
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.6
>Reporter: karthikp
>Assignee: Ted Yu
>Priority: Critical
>
> I'd memory leak issue in regionserver process, VM and RSS memory continiously 
> increasing 64MB.
> I'm using hbase-0.94.6 , MALLOC_ARENA_MAX=4 was set in hbase-env.sh
> I've huge write load and frequent minor compaction, We've used GZip hfile 
> compression.
> Max java regionserver heap size is 32GB.
> {noformat}
> top - 14:28:30 up 201 days, 21:06,  3 users,  load average: 5.67, 3.72, 3.31
> Tasks: 803 total,   1 running, 802 sleeping,   0 stopped,   0 zombie
> Cpu(s):  8.3%us,  2.1%sy,  0.0%ni, 85.9%id,  3.5%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:  65932340k total, 63961912k used,  1970428k free,  2394528k buffers
> Swap: 29659132k total,63532k used, 29595600k free,  1095268k cached
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>  57335 hbase 20   0 46.4g  44g 9296 S 98.2 70.9  13319:10 java
> {noformat}
> {noformat}
>  [hbase@xx-hslave ~]$  pmap -x 57335 | sort -k 3 -nr | more
> total kB48695984 46765792 46756512
> 7ff31246 33171072 33169464 33169464 rwx--[ anon ]
> 4010a000 1448552 1448552 1448552 rwx--[ anon ]
> 7ff2d181  612120  603124  603124 rwx--[ anon ]
> 7ff2fadff000  383364  383364  383364 rwx--[ anon ]
> 7ff0e800  131072  131072  131072 rwx--[ anon ]
> 7ff21800  131048  131048  131048 rwx--[ anon ]
> 7ff12800  131068  131048  131048 rwx--[ anon ]
> 7ff23000  131044  131044  131044 rwx--[ anon ]
> 7ff0  131036  131036  131036 rwx--[ anon ]
> 7fefe000  131060  131036  131036 rwx--[ anon ]
> 7ff23c00   65536   65536   65536 rwx--[ anon ]
> 7ff0a400   65536   65536   65536 rwx--[ anon ]
> 7ff05400   65536   65536   65536 rwx--[ anon ]
> 7ff01c00   65536   65536   65536 rwx--[ anon ]
> 7fefb400   65536   65536   65536 rwx--[ anon ]
> 7ff22c00   65532   65532   65532 rwx--[ anon ]
> 7ff11000   65532   65532   65532 rwx--[ anon ]
> 7ff10c00   65532   65532   65532 rwx--[ anon ]
> 7ff0b800   65532   65532   65532 rwx--[ anon ]
> 7ff09c00   65532   65532   65532 rwx--[ anon ]
> 7feff800   65532   65532   65532 rwx--[ anon ]
> 7ff25000   65528   65528   65528 rwx--[ anon ]
> --More--
> {noformat}
> {noformat}
> $pmap -x 57335 | awk '{print $3}' | awk '{ if($i<65536 && $i>64000) print 
> $i}' | wc -l
> 146
> {noformat}
> Will MALLOC_AREANA have exactly 65536KB? 
> Regionserver process has many anon pages, size varying from 64000 to 65536 KB 
> that shown above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15309) GZIP HFile Compression & Decompression Memory Leak, Similar Issue HBASE-5516

[karthikp (JIRA)]

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

karthikp updated HBASE-15309:
-
Assignee: (was: Ted Yu)

> GZIP HFile Compression & Decompression Memory Leak, Similar Issue HBASE-5516
> 
>
> Key: HBASE-15309
> URL: https://issues.apache.org/jira/browse/HBASE-15309
> Project: HBase
>  Issue Type: Bug
>  Components: HFile
>Affects Versions: 0.94.6
>Reporter: karthikp
>Priority: Critical
>
> I'd memory leak issue in regionserver process, VM and RSS memory continiously 
> increasing 64MB.
> I'm using hbase-0.94.6 , MALLOC_ARENA_MAX=4 was set in hbase-env.sh
> I've huge write load and frequent minor compaction, We've used GZip hfile 
> compression.
> Max java regionserver heap size is 32GB.
> {noformat}
> top - 14:28:30 up 201 days, 21:06,  3 users,  load average: 5.67, 3.72, 3.31
> Tasks: 803 total,   1 running, 802 sleeping,   0 stopped,   0 zombie
> Cpu(s):  8.3%us,  2.1%sy,  0.0%ni, 85.9%id,  3.5%wa,  0.0%hi,  0.1%si,  0.0%st
> Mem:  65932340k total, 63961912k used,  1970428k free,  2394528k buffers
> Swap: 29659132k total,63532k used, 29595600k free,  1095268k cached
>  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>  57335 hbase 20   0 46.4g  44g 9296 S 98.2 70.9  13319:10 java
> {noformat}
> {noformat}
>  [hbase@xx-hslave ~]$  pmap -x 57335 | sort -k 3 -nr | more
> total kB48695984 46765792 46756512
> 7ff31246 33171072 33169464 33169464 rwx--[ anon ]
> 4010a000 1448552 1448552 1448552 rwx--[ anon ]
> 7ff2d181  612120  603124  603124 rwx--[ anon ]
> 7ff2fadff000  383364  383364  383364 rwx--[ anon ]
> 7ff0e800  131072  131072  131072 rwx--[ anon ]
> 7ff21800  131048  131048  131048 rwx--[ anon ]
> 7ff12800  131068  131048  131048 rwx--[ anon ]
> 7ff23000  131044  131044  131044 rwx--[ anon ]
> 7ff0  131036  131036  131036 rwx--[ anon ]
> 7fefe000  131060  131036  131036 rwx--[ anon ]
> 7ff23c00   65536   65536   65536 rwx--[ anon ]
> 7ff0a400   65536   65536   65536 rwx--[ anon ]
> 7ff05400   65536   65536   65536 rwx--[ anon ]
> 7ff01c00   65536   65536   65536 rwx--[ anon ]
> 7fefb400   65536   65536   65536 rwx--[ anon ]
> 7ff22c00   65532   65532   65532 rwx--[ anon ]
> 7ff11000   65532   65532   65532 rwx--[ anon ]
> 7ff10c00   65532   65532   65532 rwx--[ anon ]
> 7ff0b800   65532   65532   65532 rwx--[ anon ]
> 7ff09c00   65532   65532   65532 rwx--[ anon ]
> 7feff800   65532   65532   65532 rwx--[ anon ]
> 7ff25000   65528   65528   65528 rwx--[ anon ]
> --More--
> {noformat}
> {noformat}
> $pmap -x 57335 | awk '{print $3}' | awk '{ if($i<65536 && $i>64000) print 
> $i}' | wc -l
> 146
> {noformat}
> Will MALLOC_AREANA have exactly 65536KB? 
> Regionserver process has many anon pages, size varying from 64000 to 65536 KB 
> that shown above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15236) Inconsistent cell reads over multiple bulk-loaded HFiles

[Appy (JIRA)]

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

Appy updated HBASE-15236:
-
Description: 
If there are two bulkloaded hfiles in a region with same seqID, same timestamps 
and duplicate keys*, get and scan may return different values for a key. Not 
sure how this would happen, but one of our customer uploaded a dataset with 2 
files in a single region and both having same bulk load timestamp. These files 
are small ~50M (I couldn't find any setting for max file size that could lead 
to 2 files). The range of keys in two hfiles are overlapping to some extent, 
but not fully (so the two files are because of region merge).
In such a case, depending on file sizes (because we take it into account when 
sorting hfiles internally), we may get different values for the same cell (say 
"r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" "cf:".

I have been able to replicate this issue, will post the instructions shortly.

---
\* 

  was:
If there are two bulkloaded hfiles in a region with same seqID and duplicate 
keys*, get and scan may return different values for a key.
More details:
- one of the rows had 200k+ columns. say row is 'r', column family is 'cf' and 
column qualifiers are 1 to 1000.
- hfiles were split somewhere along that row, but there were a range of columns 
in both hfiles. For eg, something like - hfile1: ["",  r:cf:70) and hfile2: 
[r:cf:40, ).
- Between columns 40 to 70, some (not all) columns were in both the files with 
different values. Whereas other were only in one of the files.

In such a case, depending on file size (because we take it into account when 
sorting hfiles internally), we may get different values for the same cell (say 
"r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" "cf:".

I have been able to replicate this issue, will post the instructions shortly.

---
\* not sure how this would happen. These files are small ~50M, nor could i find 
any setting for max file size that could lead to splits. Need to investigate 
more.


> Inconsistent cell reads over multiple bulk-loaded HFiles
> 
>
> Key: HBASE-15236
> URL: https://issues.apache.org/jira/browse/HBASE-15236
> Project: HBase
>  Issue Type: Bug
>Reporter: Appy
>Assignee: Appy
>
> If there are two bulkloaded hfiles in a region with same seqID, same 
> timestamps and duplicate keys*, get and scan may return different values for 
> a key. Not sure how this would happen, but one of our customer uploaded a 
> dataset with 2 files in a single region and both having same bulk load 
> timestamp. These files are small ~50M (I couldn't find any setting for max 
> file size that could lead to 2 files). The range of keys in two hfiles are 
> overlapping to some extent, but not fully (so the two files are because of 
> region merge).
> In such a case, depending on file sizes (because we take it into account when 
> sorting hfiles internally), we may get different values for the same cell 
> (say "r", "cf:50") depending on what we call: get "r" "cf:50" or get "r" 
> "cf:".
> I have been able to replicate this issue, will post the instructions shortly.
> ---
> \* 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[Anoop Sam John (JIRA)]

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

Anoop Sam John commented on HBASE-14099:


Need to see all other Fake cell usages..  We have SettableTimestamp also but 
that is needed only in write path I believe.  Ya to be on safe side make top 
level itself as SettableSequenceId, I would say

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, 
> hfiles_and_testclass.zip, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createFirstOnRow(scan.getStopRow()) : 
> KeyValueUtil.createFirstOnRow(scan
>   .getStartRow());
>   KeyValue largestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createLastOnRow(scan.getStartRow()) : 
> KeyValueUtil.createLastOnRow(scan
>   .getStopRow());
> {code}
> This row need not be copied now considering that we have 
> CellComparator.compareRows(Cell, byte[]). 
> We have already refactored the firstKeyKv and lastKeyKV as part of other 
> JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15181) A simple implementation of date based tiered compaction

[Clara Xiong (JIRA)]

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

Clara Xiong commented on HBASE-15181:
-

[~enis]I am wondering how we have maintained mvcc with 
Ratio-basedCompactionPolicy and its derived class ExploringCompactonPolicy when 
we allow filtering bulk-load and skip large files? I followed them to make the 
behavior consistent. But I wonder whether that will allow non-contiguous 
compaction. By default, they are turned off.

> A simple implementation of date based tiered compaction
> ---
>
> Key: HBASE-15181
> URL: https://issues.apache.org/jira/browse/HBASE-15181
> Project: HBase
>  Issue Type: New Feature
>  Components: Compaction
>Reporter: Clara Xiong
>Assignee: Clara Xiong
> Fix For: 2.0.0, 1.3.0, 0.98.19
>
> Attachments: HBASE-15181-v1.patch, HBASE-15181-v2.patch
>
>
> This is a simple implementation of date-based tiered compaction similar to 
> Cassandra's for the following benefits:
> 1. Improve date-range-based scan by structuring store files in date-based 
> tiered layout.
> 2. Reduce compaction overhead.
> 3. Improve TTL efficiency.
> Perfect fit for the use cases that:
> 1. has mostly date-based date write and scan and a focus on the most recent 
> data. 
> 2. never or rarely deletes data.
> Out-of-order writes are handled gracefully so the data will still get to the 
> right store file for time-range-scan and re-compacton with existing store 
> file in the same time window is handled by ExploringCompactionPolicy.
> Time range overlapping among store files is tolerated and the performance 
> impact is minimized.
> Configuration can be set at hbase-site or overriden at per-table or 
> per-column-famly level by hbase shell.
> Design spec is at 
> https://docs.google.com/document/d/1_AmlNb2N8Us1xICsTeGDLKIqL6T-oHoRLZ323MG_uy8/edit?usp=sharing



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan commented on HBASE-14099:


May be make 'EmptyCell' also as SettableSequenceId type?

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, 
> hfiles_and_testclass.zip, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createFirstOnRow(scan.getStopRow()) : 
> KeyValueUtil.createFirstOnRow(scan
>   .getStartRow());
>   KeyValue largestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createLastOnRow(scan.getStartRow()) : 
> KeyValueUtil.createLastOnRow(scan
>   .getStopRow());
> {code}
> This row need not be copied now considering that we have 
> CellComparator.compareRows(Cell, byte[]). 
> We have already refactored the firstKeyKv and lastKeyKV as part of other 
> JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15309) GZIP HFile Compression & Decompression Memory Leak, Similar Issue HBASE-5516

[karthikp (JIRA)]

karthikp created HBASE-15309:


 Summary: GZIP HFile Compression & Decompression Memory Leak, 
Similar Issue HBASE-5516
 Key: HBASE-15309
 URL: https://issues.apache.org/jira/browse/HBASE-15309
 Project: HBase
  Issue Type: Bug
  Components: HFile
Affects Versions: 0.94.6
Reporter: karthikp
Priority: Critical


I'd memory leak issue in regionserver process, VM and RSS memory continiously 
increasing 64MB.
I'm using hbase-0.94.6 , MALLOC_ARENA_MAX=4 was set in hbase-env.sh
I've huge write load and frequent minor compaction, We've used GZip hfile 
compression.
Max java regionserver heap size is 32GB.


{noformat}
top - 14:28:30 up 201 days, 21:06,  3 users,  load average: 5.67, 3.72, 3.31
Tasks: 803 total,   1 running, 802 sleeping,   0 stopped,   0 zombie
Cpu(s):  8.3%us,  2.1%sy,  0.0%ni, 85.9%id,  3.5%wa,  0.0%hi,  0.1%si,  0.0%st
Mem:  65932340k total, 63961912k used,  1970428k free,  2394528k buffers
Swap: 29659132k total,63532k used, 29595600k free,  1095268k cached

 PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 57335 hbase 20   0 46.4g  44g 9296 S 98.2 70.9  13319:10 java
{noformat}

{noformat}
 [hbase@xx-hslave ~]$  pmap -x 57335 | sort -k 3 -nr | more
total kB48695984 46765792 46756512
7ff31246 33171072 33169464 33169464 rwx--[ anon ]
4010a000 1448552 1448552 1448552 rwx--[ anon ]
7ff2d181  612120  603124  603124 rwx--[ anon ]
7ff2fadff000  383364  383364  383364 rwx--[ anon ]
7ff0e800  131072  131072  131072 rwx--[ anon ]
7ff21800  131048  131048  131048 rwx--[ anon ]
7ff12800  131068  131048  131048 rwx--[ anon ]
7ff23000  131044  131044  131044 rwx--[ anon ]
7ff0  131036  131036  131036 rwx--[ anon ]
7fefe000  131060  131036  131036 rwx--[ anon ]
7ff23c00   65536   65536   65536 rwx--[ anon ]
7ff0a400   65536   65536   65536 rwx--[ anon ]
7ff05400   65536   65536   65536 rwx--[ anon ]
7ff01c00   65536   65536   65536 rwx--[ anon ]
7fefb400   65536   65536   65536 rwx--[ anon ]
7ff22c00   65532   65532   65532 rwx--[ anon ]
7ff11000   65532   65532   65532 rwx--[ anon ]
7ff10c00   65532   65532   65532 rwx--[ anon ]
7ff0b800   65532   65532   65532 rwx--[ anon ]
7ff09c00   65532   65532   65532 rwx--[ anon ]
7feff800   65532   65532   65532 rwx--[ anon ]
7ff25000   65528   65528   65528 rwx--[ anon ]
--More--
{noformat}

{noformat}
$pmap -x 57335 | awk '{print $3}' | awk '{ if($i<65536 && $i>64000) print $i}' 
| wc -l
146
{noformat}

Will MALLOC_AREANA have exactly 65536KB? 
Regionserver process has many anon pages, size varying from 64000 to 65536 KB 
that shown above.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15205) Do not find the replication scope for every WAL#append()

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan commented on HBASE-15205:


There are some couple of tests failing. After your final review I will update 
the patch correcting the failing test cases.

> Do not find the replication scope for every WAL#append()
> 
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
>  Issue Type: Sub-task
>  Components: regionserver
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch, 
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch, 
> HBASE-15205_4.patch, HBASE-15205_6.patch, HBASE-15205_6.patch, 
> ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though 
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication 
> scope associate with the families associated with the TableDescriptor. I 
> think per WAL append doing this is very costly and creates lot of garbage. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-13259) mmap() based BucketCache IOEngine

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-13259:
---
Status: Patch Available  (was: Open)

> mmap() based BucketCache IOEngine
> -
>
> Key: HBASE-13259
> URL: https://issues.apache.org/jira/browse/HBASE-13259
> Project: HBase
>  Issue Type: New Feature
>  Components: BlockCache
>Affects Versions: 0.98.10
>Reporter: Zee Chen
>Assignee: Zee Chen
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13259-v2.patch, HBASE-13259.patch, 
> HBASE-13259_v3.patch, HBASE-13259_v4.patch, HBASE-13259_v5.patch, 
> ioread-1.svg, mmap-0.98-v1.patch, mmap-1.svg, mmap-trunk-v1.patch
>
>
> Of the existing BucketCache IOEngines, FileIOEngine uses pread() to copy data 
> from kernel space to user space. This is a good choice when the total working 
> set size is much bigger than the available RAM and the latency is dominated 
> by IO access. However, when the entire working set is small enough to fit in 
> the RAM, using mmap() (and subsequent memcpy()) to move data from kernel 
> space to user space is faster. I have run some short keyval gets tests and 
> the results indicate a reduction of 2%-7% of kernel CPU on my system, 
> depending on the load. On the gets, the latency histograms from mmap() are 
> identical to those from pread(), but peak throughput is close to 40% higher.
> This patch modifies ByteByfferArray to allow it to specify a backing file.
> Example for using this feature: set  hbase.bucketcache.ioengine to 
> mmap:/dev/shm/bucketcache.0 in hbase-site.xml.
> Attached perf measured CPU usage breakdown in flames graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-13259) mmap() based BucketCache IOEngine

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-13259:
---
Attachment: HBASE-13259_v5.patch

Updated patch. This applies cleanly and solves the whitespaces and checkstyle 
comments.

> mmap() based BucketCache IOEngine
> -
>
> Key: HBASE-13259
> URL: https://issues.apache.org/jira/browse/HBASE-13259
> Project: HBase
>  Issue Type: New Feature
>  Components: BlockCache
>Affects Versions: 0.98.10
>Reporter: Zee Chen
>Assignee: Zee Chen
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13259-v2.patch, HBASE-13259.patch, 
> HBASE-13259_v3.patch, HBASE-13259_v4.patch, HBASE-13259_v5.patch, 
> ioread-1.svg, mmap-0.98-v1.patch, mmap-1.svg, mmap-trunk-v1.patch
>
>
> Of the existing BucketCache IOEngines, FileIOEngine uses pread() to copy data 
> from kernel space to user space. This is a good choice when the total working 
> set size is much bigger than the available RAM and the latency is dominated 
> by IO access. However, when the entire working set is small enough to fit in 
> the RAM, using mmap() (and subsequent memcpy()) to move data from kernel 
> space to user space is faster. I have run some short keyval gets tests and 
> the results indicate a reduction of 2%-7% of kernel CPU on my system, 
> depending on the load. On the gets, the latency histograms from mmap() are 
> identical to those from pread(), but peak throughput is close to 40% higher.
> This patch modifies ByteByfferArray to allow it to specify a backing file.
> Example for using this feature: set  hbase.bucketcache.ioengine to 
> mmap:/dev/shm/bucketcache.0 in hbase-site.xml.
> Attached perf measured CPU usage breakdown in flames graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-13259) mmap() based BucketCache IOEngine

[ramkrishna.s.vasudevan (JIRA)]

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

ramkrishna.s.vasudevan updated HBASE-13259:
---
Status: Open  (was: Patch Available)

> mmap() based BucketCache IOEngine
> -
>
> Key: HBASE-13259
> URL: https://issues.apache.org/jira/browse/HBASE-13259
> Project: HBase
>  Issue Type: New Feature
>  Components: BlockCache
>Affects Versions: 0.98.10
>Reporter: Zee Chen
>Assignee: Zee Chen
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-13259-v2.patch, HBASE-13259.patch, 
> HBASE-13259_v3.patch, HBASE-13259_v4.patch, HBASE-13259_v5.patch, 
> ioread-1.svg, mmap-0.98-v1.patch, mmap-1.svg, mmap-trunk-v1.patch
>
>
> Of the existing BucketCache IOEngines, FileIOEngine uses pread() to copy data 
> from kernel space to user space. This is a good choice when the total working 
> set size is much bigger than the available RAM and the latency is dominated 
> by IO access. However, when the entire working set is small enough to fit in 
> the RAM, using mmap() (and subsequent memcpy()) to move data from kernel 
> space to user space is faster. I have run some short keyval gets tests and 
> the results indicate a reduction of 2%-7% of kernel CPU on my system, 
> depending on the load. On the gets, the latency histograms from mmap() are 
> identical to those from pread(), but peak throughput is close to 40% higher.
> This patch modifies ByteByfferArray to allow it to specify a backing file.
> Example for using this feature: set  hbase.bucketcache.ioengine to 
> mmap:/dev/shm/bucketcache.0 in hbase-site.xml.
> Attached perf measured CPU usage breakdown in flames graph.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads

[stack (JIRA)]

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

stack updated HBASE-15232:
--
   Resolution: Fixed
Fix Version/s: (was: 1.1.4)
   (was: 1.2.1)
   (was: 1.3.0)
   Status: Resolved  (was: Patch Available)

Applied to master branch. Doesn't go into branch-1. If you put up a version for 
branch-1, I'll commit. Thanks for the patch [~elserj]

> Exceptions returned over multi RPC don't automatically trigger region 
> location reloads
> --
>
> Key: HBASE-15232
> URL: https://issues.apache.org/jira/browse/HBASE-15232
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0
>
> Attachments: HBASE-15232.001.patch, HBASE-15232.002.patch, 
> HBASE-15232.002.patch
>
>
> Follow-on for HBASE-15221:
> A work-around was added in HTableMultiplexer to work around an issue that 
> AsyncProcess wasn't clearing the region location cache on Exception. This was 
> stemming from the issue that the {{tableName}} is {{null}} because 
> HTableMultiplexer is using the {{multi}} RPC. This causes an error that looks 
> like:
> {noformat}
> [WARN] Coding error, see method javadoc. row=[B@1673eff, tableName=null
> {noformat}
> HBASE-15221 should fix HTableMultiplexer, but it would be good to push the 
> fix down into AsyncProcess instead of using higher-level workarounds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15301) Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS method signature

[stack (JIRA)]

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

stack updated HBASE-15301:
--
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: 2.0.0
   Status: Resolved  (was: Patch Available)

Applied to master. Doesn't apply clean on branch-1. Thanks [~carp84] for the 
patch.

> Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS 
> method signature
> -
>
> Key: HBASE-15301
> URL: https://issues.apache.org/jira/browse/HBASE-15301
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.2.0, 1.1.3
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15301.patch
>
>
> When fixing HBASE-15185, I found that after HBASE-12115 NamingException is 
> handled inside {{TableInputFormatBase#reverseDNS}}, and we should remove it 
> from the throws declaration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[Anoop Sam John (JIRA)]

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

Anoop Sam John commented on HBASE-14099:


Ya this will come for scanners on a bulk loaded file only..  That is why no 
tests found it.  We need to make some of the Fake cells at least as 
SettableSequenceId type. (Or all to be on safe side).  This went in only in 2.0 
so an addendum to fix the issue is fine. (No need for new issue)..

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, 
> hfiles_and_testclass.zip, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createFirstOnRow(scan.getStopRow()) : 
> KeyValueUtil.createFirstOnRow(scan
>   .getStartRow());
>   KeyValue largestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createLastOnRow(scan.getStartRow()) : 
> KeyValueUtil.createLastOnRow(scan
>   .getStopRow());
> {code}
> This row need not be copied now considering that we have 
> CellComparator.compareRows(Cell, byte[]). 
> We have already refactored the firstKeyKv and lastKeyKV as part of other 
> JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[Appy (JIRA)]

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

Appy updated HBASE-14099:
-
Attachment: hfiles_and_testclass.zip

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, 
> hfiles_and_testclass.zip, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createFirstOnRow(scan.getStopRow()) : 
> KeyValueUtil.createFirstOnRow(scan
>   .getStartRow());
>   KeyValue largestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createLastOnRow(scan.getStartRow()) : 
> KeyValueUtil.createLastOnRow(scan
>   .getStopRow());
> {code}
> This row need not be copied now considering that we have 
> CellComparator.compareRows(Cell, byte[]). 
> We have already refactored the firstKeyKv and lastKeyKV as part of other 
> JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[Appy (JIRA)]

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

Appy reopened HBASE-14099:
--

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createFirstOnRow(scan.getStopRow()) : 
> KeyValueUtil.createFirstOnRow(scan
>   .getStartRow());
>   KeyValue largestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   .createLastOnRow(scan.getStartRow()) : 
> KeyValueUtil.createLastOnRow(scan
>   .getStopRow());
> {code}
> This row need not be copied now considering that we have 
> CellComparator.compareRows(Cell, byte[]). 
> We have already refactored the firstKeyKv and lastKeyKV as part of other 
> JIRAs.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14099) StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start and stop Row

[Appy (JIRA)]

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

Appy commented on HBASE-14099:
--

I was doing some testing when I hit a weird issue, seems related to this, so 
re-opening it (apologies in advance if it's not).  Here's the stack trace
{noformat}
java.io.IOException: java.lang.UnsupportedOperationException: Cell is not of 
type org.apache.hadoop.hbase.SettableSequenceId

at org.apache.hadoop.hbase.CellUtil.setSequenceId(CellUtil.java:923)
at 
org.apache.hadoop.hbase.regionserver.StoreFileScanner.setCurrentCell(StoreFileScanner.java:231)
at 
org.apache.hadoop.hbase.regionserver.StoreFileScanner.requestSeek(StoreFileScanner.java:389)
at 
org.apache.hadoop.hbase.regionserver.StoreScanner.seekScanners(StoreScanner.java:348)
at 
org.apache.hadoop.hbase.regionserver.StoreScanner.(StoreScanner.java:212)
at 
org.apache.hadoop.hbase.regionserver.HStore.createScanner(HStore.java:1873)
at 
org.apache.hadoop.hbase.regionserver.HStore.getScanner(HStore.java:1863)
at 
org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.(HRegion.java:5487)
at 
org.apache.hadoop.hbase.regionserver.HRegion.instantiateRegionScanner(HRegion.java:2577)
at 
org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2563)
at 
org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2544)
at 
org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2534)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6659)
at org.apache.hadoop.hbase.regionserver.HRegion.get(HRegion.java:6624)
at 
org.apache.hadoop.hbase.regionserver.TestWithSingleHRegion.test(TestWithSingleHRegion.java:48)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
{noformat}

I think it's because of using changing from KeyValue to a different sub-class 
of {{Cell}}l which doesn't implement {{SettableSequenceId}}
{noformat}
-this.startKey = 
KeyValueUtil.createFirstDeleteFamilyOnRow(scan.getStartRow(),
+this.startKey = 
CellUtil.createFirstDeleteFamilyCellOnRow(scan.getStartRow(),
{noformat}

To replicate it, download the attached hfiles somewhere, copy the 
TestWithSingleHRegion class to regionserver tests, change the ROOT_DIR 
appropriately and run it.

> StoreFile.passesKeyRangeFilter need not create Cells from the Scan's start 
> and stop Row
> ---
>
> Key: HBASE-14099
> URL: https://issues.apache.org/jira/browse/HBASE-14099
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance, Scanners
>Reporter: ramkrishna.s.vasudevan
>Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: HBASE-14099.patch, HBASE-14099_1.patch, 
> HBASE-14099_2.patch, HBASE-14099_3.patch, HBASE-14099_4.patch, storefile.png
>
>
> During profiling saw that the code here in passesKeyRangeFilter in Storefile
> {code}
>   KeyValue smallestScanKeyValue = scan.isReversed() ? KeyValueUtil
>   

[jira] [Commented] (HBASE-14878) maven archetype: client application with shaded jars

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-14878:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:red}-1{color} | {color:red} docker {color} | {color:red} 8m 16s 
{color} | {color:red} Docker failed to build yetus/hbase:date2016-02-23. 
{color} |
\\
\\
|| Subsystem || Report/Notes ||
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12789129/HBASE-14878-v1.patch |
| JIRA Issue | HBASE-14878 |
| Powered by | Apache Yetus 0.1.0   http://yetus.apache.org |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/643/console |


This message was automatically generated.



> maven archetype: client application with shaded jars
> 
>
> Key: HBASE-14878
> URL: https://issues.apache.org/jira/browse/HBASE-14878
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: beginner
> Attachments: HBASE-14878-v1.patch
>
>
> Add new archetype for generation of hbase-shaded-client dependent project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14876) Provide maven archetypes

[Daniel Vimont (JIRA)]

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

Daniel Vimont commented on HBASE-14876:
---

FYI, just submitted patch for subtask HBASE-14878 (hbase-shaded-client 
archetype).

> Provide maven archetypes
> 
>
> Key: HBASE-14876
> URL: https://issues.apache.org/jira/browse/HBASE-14876
> Project: HBase
>  Issue Type: New Feature
>  Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: beginner, maven
> Attachments: HBASE-14876-v2.patch, HBASE-14876.patch, 
> archetype_prototype.zip, archetype_prototype02.zip, 
> archetype_shaded_prototype01.zip
>
>
> To help onboard new users, we should provide maven archetypes for hbase 
> client applications. Off the top of my head, we should have templates for
>  - hbase client application with all dependencies
>  - hbase client application using client-shaded jar
>  - mapreduce application with hbase as input and output (ie, copy table)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars

[Daniel Vimont (JIRA)]

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

Daniel Vimont updated HBASE-14878:
--
 Release Note: Adds new hbase-shaded-client archetype; also corrects an 
omission found in hbase-archetypes/README.md in the section headed "How to add 
a new archetype".
Affects Version/s: 2.0.0
 Tags: archetype, hbase-shaded-client
   Status: Patch Available  (was: Open)

Submitting patch HBASE-14878-v1.patch:

Adds new hbase-shaded-client archetype; also corrects an omission found in 
hbase-archetypes/README.md in the section headed "How to add a new archetype".


> maven archetype: client application with shaded jars
> 
>
> Key: HBASE-14878
> URL: https://issues.apache.org/jira/browse/HBASE-14878
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: beginner
> Attachments: HBASE-14878-v1.patch
>
>
> Add new archetype for generation of hbase-shaded-client dependent project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14877) maven archetype: client application

[Daniel Vimont (JIRA)]

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

Daniel Vimont commented on HBASE-14877:
---

FYI, just submitted patch for subtask HBASE-14878 (hbase-shaded-client 
archetype).

> maven archetype: client application
> ---
>
> Key: HBASE-14877
> URL: https://issues.apache.org/jira/browse/HBASE-14877
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: archetype, beginner, maven
> Fix For: 2.0.0
>
> Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, 
> HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, 
> HBASE-14877.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars

[Daniel Vimont (JIRA)]

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

Daniel Vimont updated HBASE-14878:
--
Attachment: HBASE-14878-v1.patch

> maven archetype: client application with shaded jars
> 
>
> Key: HBASE-14878
> URL: https://issues.apache.org/jira/browse/HBASE-14878
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: beginner
> Attachments: HBASE-14878-v1.patch
>
>
> Add new archetype for generation of hbase-shaded-client dependent project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-14878) maven archetype: client application with shaded jars

[Daniel Vimont (JIRA)]

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

Daniel Vimont updated HBASE-14878:
--
Description: Add new archetype for generation of hbase-shaded-client 
dependent project.

> maven archetype: client application with shaded jars
> 
>
> Key: HBASE-14878
> URL: https://issues.apache.org/jira/browse/HBASE-14878
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: beginner
>
> Add new archetype for generation of hbase-shaded-client dependent project.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15222:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
44s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m 
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 57s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 15s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 11s 
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 2s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 13s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 13s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 7s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-common 
(total was 1, now 1). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 14s 
{color} | {color:red} Patch generated 6 new checkstyle issues in 
hbase-hadoop2-compat (total was 67, now 51). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 23s 
{color} | {color:red} Patch generated 4 new checkstyle issues in hbase-server 
(total was 194, now 195). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
46s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
1s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 0s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
24m 32s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
52s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 59s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 12s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 34s 
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 17s 
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 15s 
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} 

[jira] [Comment Edited] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property

[Anoop Sam John (JIRA)]

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

Anoop Sam John edited comment on HBASE-15247 at 2/23/16 4:30 AM:
-

Pushed to master and branch-1.
Thanks for the patch Amal


was (Author: anoop.hbase):
Pushed to master and branch-1.

> InclusiveStopFilter does not respect reverse Filter property
> 
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter 
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed 
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15247) InclusiveStopFilter does not respect reverse Filter property

[Anoop Sam John (JIRA)]

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

Anoop Sam John updated HBASE-15247:
---
   Resolution: Fixed
 Hadoop Flags: Reviewed
Fix Version/s: (was: 1.1.1)
   Status: Resolved  (was: Patch Available)

Pushed to master and branch-1.

> InclusiveStopFilter does not respect reverse Filter property
> 
>
> Key: HBASE-15247
> URL: https://issues.apache.org/jira/browse/HBASE-15247
> Project: HBase
>  Issue Type: Bug
>  Components: Filters
>Affects Versions: 2.0.0, 1.1.1
>Reporter: Rick Moritz
>Assignee: Amal Joshy
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15247-branch-1.1.patch, HBASE-15247.patch
>
>
> InclusiveStopFilter only works with non-reversed Scans, it will not filter 
> for reversed Scans, because it doesn't flip the cmp-operand in the reversed 
> case. In fact, it doesn't even use the Filter.reverse flag.
> it should be something like this:
> if (reversed) {
> if (cmp > 0) {
> done = true;
> }
> }
> else {
> if (cmp < 0) {
> done = true;
> }
> }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15305:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s 
{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
15s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 5s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 45s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
13s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
15s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
29m 26s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 2m 12s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 3m 2s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 118m 2s {color} 
| {color:red} root in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 138m 57s 
{color} | {color:green} root in the patch passed with JDK v1.7.0_95. {color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
26s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 306m 54s {color} 
| {color:black} {color} |
\\
\\
|| Reason || Tests ||
| JDK v1.8.0_72 Failed junit tests | 
hadoop.hbase.client.TestBlockEvictionFromClient |
| JDK v1.8.0_72 Timed out junit tests | 
org.apache.hadoop.hbase.regionserver.TestRegionMergeTransactionOnCluster |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-22 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12789084/HBASE-15305.patch |
| JIRA Issue | HBASE-15305 |
| Optional Tests |  asflicense  javac  javadoc  unit  |
| uname | Linux 157f2139aedc 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed 
Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | 
/home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build/component/dev-support/hbase-personality.sh
 |
| git revision | master / 2966eee |
| unit | 
https://builds.apache.org/job/PreCommit-HBASE-Build/640/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
 |
| unit test logs |  
https://builds.apache.org/job/PreCommit-HBASE-Build/640/artifact/patchprocess/patch-unit-root-jdk1.8.0_72.txt
 |
| JDK v1.7.0_95  Test Results | 
https://builds.apache.org/job/PreCommit-HBASE-Build/640/testReport/ |
| modules | C: . U: . |
| Max memory used | 186MB |
| Powered by | Apache Yetus 0.1.0   http://yetus.apache.org |
| Console output | 
https://builds.apache.org/job/PreCommit-HBASE-Build/640/console |


This message was automatically generated.



> Fix a couple of incorrect anchors in HBase ref guide
> 
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are 

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Status: Open  (was: Patch Available)

> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Status: Patch Available  (was: Open)

> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Attachment: HBASE-15306-v2.patch

implemented checks for RW balancer, added test

> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15306-v1.patch, HBASE-15306-v2.patch
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15301) Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS method signature

[Yu Li (JIRA)]

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

Yu Li updated HBASE-15301:
--
Affects Version/s: 2.0.0
   1.2.0
   1.1.3

> Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS 
> method signature
> -
>
> Key: HBASE-15301
> URL: https://issues.apache.org/jira/browse/HBASE-15301
> Project: HBase
>  Issue Type: Improvement
>Affects Versions: 2.0.0, 1.2.0, 1.1.3
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Attachments: HBASE-15301.patch
>
>
> When fixing HBASE-15185, I found that after HBASE-12115 NamingException is 
> handled inside {{TableInputFormatBase#reverseDNS}}, and we should remove it 
> from the throws declaration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15301) Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS method signature

[Yu Li (JIRA)]

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

Yu Li commented on HBASE-15301:
---

I think this applies to both 2.0 and branch-1, let me update the affect 
versions, thanks.

> Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS 
> method signature
> -
>
> Key: HBASE-15301
> URL: https://issues.apache.org/jira/browse/HBASE-15301
> Project: HBase
>  Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Attachments: HBASE-15301.patch
>
>
> When fixing HBASE-15185, I found that after HBASE-12115 NamingException is 
> handled inside {{TableInputFormatBase#reverseDNS}}, and we should remove it 
> from the throws declaration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14362) org.apache.hadoop.hbase.master.procedure.TestWALProcedureStoreOnHDFS is super duper flaky

[Hudson (JIRA)]

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

Hudson commented on HBASE-14362:


FAILURE: Integrated in HBase-1.1-JDK8 #1755 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1755/])
HBASE-15169 Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super 
(chenheng: rev 10d607717257af8e83368e34bc32f98f98389dc8)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestWALProcedureStoreOnHDFS.java


> org.apache.hadoop.hbase.master.procedure.TestWALProcedureStoreOnHDFS is super 
> duper flaky
> -
>
> Key: HBASE-14362
> URL: https://issues.apache.org/jira/browse/HBASE-14362
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 2.0.0
>Reporter: Dima Spivak
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.3
>
> Attachments: HBASE-14362.patch, HBASE-14362.patch, 
> HBASE-14362_v1.patch
>
>
> [As seen in 
> Jenkins|https://builds.apache.org/job/HBase-TRUNK/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master.procedure/TestWALProcedureStoreOnHDFS/history/],
>  this test has been super flaky and we should probably address it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

[Hudson (JIRA)]

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

Hudson commented on HBASE-15169:


FAILURE: Integrated in HBase-1.1-JDK8 #1755 (See 
[https://builds.apache.org/job/HBase-1.1-JDK8/1755/])
HBASE-15169 Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super 
(chenheng: rev 10d607717257af8e83368e34bc32f98f98389dc8)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestWALProcedureStoreOnHDFS.java


> Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to 
> branch-1.1
> -
>
> Key: HBASE-15169
> URL: https://issues.apache.org/jira/browse/HBASE-15169
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 1.1.4
>
> Attachments: HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch
>
>
> This one fails consistently for me and there's a fix hanging out upstream. 
> Let's bring it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15232:
---

| (/) *{color:green}+1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
21s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 2s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
4s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
30s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 5s 
{color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 55s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 56s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
8s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 1s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 1s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 55s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 55s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
25s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 57s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
41s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 54s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 3s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 1s 
{color} | {color:green} hbase-client in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 111m 11s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 1m 8s 
{color} | {color:green} hbase-client in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 100m 56s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
30s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 276m 8s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-22 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12789060/HBASE-15232.002.patch 
|
| JIRA Issue | 

[jira] [Updated] (HBASE-15184) SparkSQL Scan operation doesn't work on kerberos cluster

[Ted Malaska (JIRA)]

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

Ted Malaska updated HBASE-15184:

Attachment: HBASE-15184.1.patch

This was tested both in unit tests and in a 10 node kerberos cluster

> SparkSQL Scan operation doesn't work on kerberos cluster
> 
>
> Key: HBASE-15184
> URL: https://issues.apache.org/jira/browse/HBASE-15184
> Project: HBase
>  Issue Type: Bug
>  Components: spark
>Reporter: Ted Malaska
>Assignee: Ted Malaska
>Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-15184.1.patch, HBaseSparkModule.zip
>
>
> I was using the HBase Spark Module at a client with Kerberos and I ran into 
> an issue with the Scan.  
> I made a fix for the client but we need to put it back into HBase.  I will 
> attach my solution, but it has a major problem.  I had to over ride a 
> protected class in spark.  I will need help to decover a better approach



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15264) Implement a fan out HDFS OutputStream

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-15264:
---

[~stack] What do you think we should go next？ On master or a new branch? 

Thanks.

> Implement a fan out HDFS OutputStream
> -
>
> Key: HBASE-15264
> URL: https://issues.apache.org/jira/browse/HBASE-15264
> Project: HBase
>  Issue Type: Sub-task
>  Components: util, wal
>Reporter: Duo Zhang
>Assignee: Duo Zhang
> Fix For: 2.0.0
>
> Attachments: HBASE-15264-v1.patch, HBASE-15264-v2.patch, 
> HBASE-15264-v3.patch, HBASE-15264-v4.patch, HBASE-15264-v5.patch, 
> HBASE-15264-v6.patch, HBASE-15264.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15222) Use less contended classes for metrics

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15222:
--
Attachment: HBASE-15222-v12.patch

Protect against divide by zero for mean.

> Use less contended classes for metrics
> --
>
> Key: HBASE-15222
> URL: https://issues.apache.org/jira/browse/HBASE-15222
> Project: HBase
>  Issue Type: Bug
>  Components: metrics
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, 
> HBASE-15222-v11.patch, HBASE-15222-v12.patch, HBASE-15222-v2.patch, 
> HBASE-15222-v3.patch, HBASE-15222-v5.patch, HBASE-15222-v6.patch, 
> HBASE-15222-v8.patch, HBASE-15222-v9.patch, HBASE-15222.patch
>
>
> Running the benchmarks now, but it looks like the results are pretty extreme. 
> The locking in our histograms is pretty extreme.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15222:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 4m 
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 41s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 32s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 7m 
8s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 
40s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 54s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 38s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 14s 
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 45s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 45s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 40s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 40s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 27s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-common 
(total was 1, now 1). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 20s 
{color} | {color:red} Patch generated 6 new checkstyle issues in 
hbase-hadoop2-compat (total was 67, now 51). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 54s 
{color} | {color:red} Patch generated 4 new checkstyle issues in hbase-server 
(total was 194, now 195). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 1m 
10s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
35m 30s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 6m 0s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 49s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 40s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 2m 18s 
{color} | {color:green} hbase-common in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 28s 
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 21s 
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit 

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Elliott Clark (JIRA)]

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

Elliott Clark commented on HBASE-15222:
---

Even on a more beefy server with 32 cores the trend seems to be the same.
{code}

Benchmark  ModeCnt  Score
Error  Units
HistogramBenchmark.fastLong  sample   35227492   3567.574 ± 
62.455  ns/op
HistogramBenchmark.testHDRAtomic sample   66502547   7451.278 ± 
27.255  ns/op
HistogramBenchmark.testHDRConcurrent sample   44092577   6178.153 ± 
24.280  ns/op
HistogramBenchmark.testMutableTimeHistogram  sample   59723205   3207.766 ± 
17.421  ns/op
HistogramBenchmark.testYammersample   55265767  14979.696 ± 
42.628  ns/op

{code}

> Use less contended classes for metrics
> --
>
> Key: HBASE-15222
> URL: https://issues.apache.org/jira/browse/HBASE-15222
> Project: HBase
>  Issue Type: Bug
>  Components: metrics
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, 
> HBASE-15222-v11.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, 
> HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, 
> HBASE-15222-v9.patch, HBASE-15222.patch
>
>
> Running the benchmarks now, but it looks like the results are pretty extreme. 
> The locking in our histograms is pretty extreme.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14877) maven archetype: client application

[Daniel Vimont (JIRA)]

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

Daniel Vimont commented on HBASE-14877:
---

Okay, since time-frames and other 1.3-oriented details are 
yet-to-be-determined, I'll go ahead with the other subtasks (HBASE-14878, 
HBASE-14879, and HBASE-15081) to get those into the master branch, while 
waiting for 1.3 plans to firm up.

> maven archetype: client application
> ---
>
> Key: HBASE-14877
> URL: https://issues.apache.org/jira/browse/HBASE-14877
> Project: HBase
>  Issue Type: Sub-task
>  Components: build, Usability
>Affects Versions: 2.0.0
>Reporter: Nick Dimiduk
>Assignee: Daniel Vimont
>  Labels: archetype, beginner, maven
> Fix For: 2.0.0
>
> Attachments: HBASE-14877-v2.patch, HBASE-14877-v3.patch, 
> HBASE-14877-v4.patch, HBASE-14877-v5.patch, HBASE-14877-v6.patch, 
> HBASE-14877.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14362) org.apache.hadoop.hbase.master.procedure.TestWALProcedureStoreOnHDFS is super duper flaky

[Hudson (JIRA)]

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

Hudson commented on HBASE-14362:


FAILURE: Integrated in HBase-1.1-JDK7 #1668 (See 
[https://builds.apache.org/job/HBase-1.1-JDK7/1668/])
HBASE-15169 Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super 
(chenheng: rev 10d607717257af8e83368e34bc32f98f98389dc8)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestWALProcedureStoreOnHDFS.java


> org.apache.hadoop.hbase.master.procedure.TestWALProcedureStoreOnHDFS is super 
> duper flaky
> -
>
> Key: HBASE-14362
> URL: https://issues.apache.org/jira/browse/HBASE-14362
> Project: HBase
>  Issue Type: Bug
>  Components: test
>Affects Versions: 2.0.0
>Reporter: Dima Spivak
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.1.3
>
> Attachments: HBASE-14362.patch, HBASE-14362.patch, 
> HBASE-14362_v1.patch
>
>
> [As seen in 
> Jenkins|https://builds.apache.org/job/HBase-TRUNK/lastCompletedBuild/testReport/org.apache.hadoop.hbase.master.procedure/TestWALProcedureStoreOnHDFS/history/],
>  this test has been super flaky and we should probably address it.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

[Hudson (JIRA)]

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

Hudson commented on HBASE-15169:


FAILURE: Integrated in HBase-1.1-JDK7 #1668 (See 
[https://builds.apache.org/job/HBase-1.1-JDK7/1668/])
HBASE-15169 Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super 
(chenheng: rev 10d607717257af8e83368e34bc32f98f98389dc8)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/master/procedure/TestWALProcedureStoreOnHDFS.java


> Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to 
> branch-1.1
> -
>
> Key: HBASE-15169
> URL: https://issues.apache.org/jira/browse/HBASE-15169
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 1.1.4
>
> Attachments: HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch
>
>
> This one fails consistently for me and there's a fix hanging out upstream. 
> Let's bring it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Elliott Clark (JIRA)]

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

Elliott Clark commented on HBASE-15222:
---

Yeah, fastLong is continually much faster than Yammer and a little bit faster 
or the same speed as HDR.

> Use less contended classes for metrics
> --
>
> Key: HBASE-15222
> URL: https://issues.apache.org/jira/browse/HBASE-15222
> Project: HBase
>  Issue Type: Bug
>  Components: metrics
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, 
> HBASE-15222-v11.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, 
> HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, 
> HBASE-15222-v9.patch, HBASE-15222.patch
>
>
> Running the benchmarks now, but it looks like the results are pretty extreme. 
> The locking in our histograms is pretty extreme.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-11927) Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to CRC32C)

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-11927:
-

is this fine to close now? if not, could we move backport to its own ticket?

> Use Native Hadoop Library for HFile checksum (And flip default from CRC32 to 
> CRC32C)
> 
>
> Key: HBASE-11927
> URL: https://issues.apache.org/jira/browse/HBASE-11927
> Project: HBase
>  Issue Type: Improvement
>  Components: Performance
>Reporter: stack
>Assignee: Appy
> Fix For: 2.0.0, 1.2.0, 1.1.4
>
> Attachments: HBASE-11927-branch-1.1.patch, HBASE-11927-v1.patch, 
> HBASE-11927-v2.patch, HBASE-11927-v4.patch, HBASE-11927-v5.patch, 
> HBASE-11927-v6.patch, HBASE-11927-v7.patch, HBASE-11927-v8.patch, 
> HBASE-11927-v8.patch, HBASE-11927.patch, after-compact-2%.svg, 
> after-randomWrite1M-0.5%.svg, before-compact-22%.svg, 
> before-randomWrite1M-5%.svg, c2021.crc2.svg, c2021.write.2.svg, 
> c2021.zip.svg, crc32ct.svg
>
>
> Up in hadoop they have this change. Let me publish some graphs to show that 
> it makes a difference (CRC is a massive amount of our CPU usage in my 
> profiling of an upload because of compacting, flushing, etc.).  We should 
> also make use of native CRCings -- especially the 2.6 HDFS-6865 and ilk -- in 
> hbase but that is another issue for now.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15285) Forward-port respect for isReturnResult from HBASE-15095

[Sean Busbey (JIRA)]

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

Sean Busbey updated HBASE-15285:

Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Forward-port respect for isReturnResult from HBASE-15095
> 
>
> Key: HBASE-15285
> URL: https://issues.apache.org/jira/browse/HBASE-15285
> Project: HBase
>  Issue Type: Bug
>  Components: Client
>Affects Versions: 2.0.0, 1.2.0
>Reporter: stack
>Assignee: stack
> Fix For: 2.0.0, 1.2.0, 1.3.0
>
> Attachments: 15095.patch, 15095v2.patch, 
> HBASE-15285-branch-1.addendum.v1.patch
>
>
> This issue is about forward-porting the bug fix done in HBASE-15095 so we 
> respect the isReturnResult properly in append and increment.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-13908) 1.2 release umbrella

[Sean Busbey (JIRA)]

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

Sean Busbey resolved HBASE-13908.
-
Resolution: Fixed

RC4 passed:

https://s.apache.org/hbase-1.2.0-rc4-vote

https://s.apache.org/hbase-1.2.0-vote-passes

release posted: http://www.apache.org/dist/hbase/1.2.0/

> 1.2 release umbrella
> 
>
> Key: HBASE-13908
> URL: https://issues.apache.org/jira/browse/HBASE-13908
> Project: HBase
>  Issue Type: Umbrella
>  Components: build
>Affects Versions: 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 1.2.0
>
>
> Umbrella for tasks related to the 1.2 release line starting.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (HBASE-14025) Update CHANGES.txt for 1.2

[Sean Busbey (JIRA)]

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

Sean Busbey resolved HBASE-14025.
-
Resolution: Fixed

> Update CHANGES.txt for 1.2
> --
>
> Key: HBASE-14025
> URL: https://issues.apache.org/jira/browse/HBASE-14025
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Affects Versions: 1.2.0
>Reporter: Sean Busbey
>Assignee: Sean Busbey
> Fix For: 1.2.0
>
>
> Since it's more effort than I expected, making a ticket to track actually 
> updating CHANGES.txt so that new RMs have an idea what to expect.
> Maybe will make doc changes if there's enough here.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15302) Reenable the other tests disabled by HBASE-14678

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15302:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:blue}0{color} | {color:blue} patch {color} | {color:blue} 0m 16s 
{color} | {color:blue} The patch file was not named according to hbase's naming 
conventions. Please see 
https://yetus.apache.org/documentation/latest/precommit-patchnames for 
instructions. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 10 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 43s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 4m 
14s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 35s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 44s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 
0s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 44s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 44s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 48s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 48s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 23s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server 
(total was 69, now 70). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
32s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
24m 18s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 2s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 45s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 89m 23s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 7m 10s 
{color} | {color:green} hbase-shell in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 84m 10s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 6m 31s 
{color} | {color:green} hbase-shell in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
31s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| 

[jira] [Commented] (HBASE-15302) Reenable the other tests disabled by HBASE-14678

[Duo Zhang (JIRA)]

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

Duo Zhang commented on HBASE-15302:
---

+1 if it pass pre commit again.

> Reenable the other tests disabled by HBASE-14678
> 
>
> Key: HBASE-15302
> URL: https://issues.apache.org/jira/browse/HBASE-15302
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Phil Yang
>Assignee: Phil Yang
> Fix For: 2.0.0, 1.3.0, 1.2.1
>
> Attachments: HBASE-15302-v1.txt, HBASE-15302-v1.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15306) Make RPC call queue length dynamically configurable

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15306:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:red}-1{color} | {color:red} test4tests {color} | {color:red} 0m 0s 
{color} | {color:red} The patch doesn't appear to include any new or modified 
tests. Please justify why no new tests are needed for this patch. Also please 
list what manual steps were performed to verify this patch. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 
48s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 3m 
59s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
17s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 1m 
54s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 32s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 36s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 0m 
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 39s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 39s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 0m 35s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 23s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-server 
(total was 97, now 98). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
17s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
24m 34s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 3s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 30s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 33s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 97m 2s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.8.0_72. 
{color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 95m 12s 
{color} | {color:green} hbase-server in the patch passed with JDK v1.7.0_95. 
{color} |
| {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 
14s {color} | {color:green} Patch does not generate ASF License warnings. 
{color} |
| {color:black}{color} | {color:black} {color} | {color:black} 238m 29s {color} 
| {color:black} {color} |
\\
\\
|| Subsystem || Report/Notes ||
| Docker | Client=1.9.1 Server=1.9.1 Image:yetus/hbase:date2016-02-22 |
| JIRA Patch URL | 
https://issues.apache.org/jira/secure/attachment/12789042/HBASE-15306-v1.patch |
| JIRA Issue | HBASE-15306 |
| Optional Tests |  asflicense  javac  javadoc  unit  findbugs  hadoopcheck  
hbaseanti  checkstyle  compile  |
| uname | Linux 

[jira] [Updated] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide

[Misty Stanley-Jones (JIRA)]

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

Misty Stanley-Jones updated HBASE-15305:

Attachment: HBASE-15305.patch

Ready for review.

> Fix a couple of incorrect anchors in HBase ref guide
> 
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are still two missing asciidoc anchors, 
> distributed.log.splitting and fail.fast.expired.active.master. These are 
> related to features removed by HBASE-14053 and HBASE-10569. I think these 
> anchors(and related texts) should be handled by someone who knows those 
> issues well, so I retain them.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15305) Fix a couple of incorrect anchors in HBase ref guide

[Misty Stanley-Jones (JIRA)]

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

Misty Stanley-Jones updated HBASE-15305:

Status: Patch Available  (was: Open)

> Fix a couple of incorrect anchors in HBase ref guide
> 
>
> Key: HBASE-15305
> URL: https://issues.apache.org/jira/browse/HBASE-15305
> Project: HBase
>  Issue Type: Sub-task
>  Components: documentation
>Reporter: Misty Stanley-Jones
>Assignee: Misty Stanley-Jones
> Fix For: 2.0.0
>
> Attachments: HBASE-15305.patch
>
>
> From HBASE-15298:
> {quote}
> After this patch is applied, there are still two missing asciidoc anchors, 
> distributed.log.splitting and fail.fast.expired.active.master. These are 
> related to features removed by HBASE-14053 and HBASE-10569. I think these 
> anchors(and related texts) should be handled by someone who knows those 
> issues well, so I retain them.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15222) Use less contended classes for metrics

[Elliott Clark (JIRA)]

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

Elliott Clark updated HBASE-15222:
--
Attachment: HBASE-15222-v11.patch

I had left some debug numbers in when creating buckets. So there were only 4 
bins.

Fixed that.

> Use less contended classes for metrics
> --
>
> Key: HBASE-15222
> URL: https://issues.apache.org/jira/browse/HBASE-15222
> Project: HBase
>  Issue Type: Bug
>  Components: metrics
>Affects Versions: 2.0.0, 1.2.0, 1.3.0
>Reporter: Elliott Clark
>Assignee: Elliott Clark
>Priority: Critical
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15222-v1.patch, HBASE-15222-v10.patch, 
> HBASE-15222-v11.patch, HBASE-15222-v2.patch, HBASE-15222-v3.patch, 
> HBASE-15222-v5.patch, HBASE-15222-v6.patch, HBASE-15222-v8.patch, 
> HBASE-15222-v9.patch, HBASE-15222.patch
>
>
> Running the benchmarks now, but it looks like the results are pretty extreme. 
> The locking in our histograms is pretty extreme.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads

[Josh Elser (JIRA)]

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

Josh Elser commented on HBASE-15232:


(argh, thanks [~saint@gmail.com])

> Exceptions returned over multi RPC don't automatically trigger region 
> location reloads
> --
>
> Key: HBASE-15232
> URL: https://issues.apache.org/jira/browse/HBASE-15232
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: HBASE-15232.001.patch, HBASE-15232.002.patch, 
> HBASE-15232.002.patch
>
>
> Follow-on for HBASE-15221:
> A work-around was added in HTableMultiplexer to work around an issue that 
> AsyncProcess wasn't clearing the region location cache on Exception. This was 
> stemming from the issue that the {{tableName}} is {{null}} because 
> HTableMultiplexer is using the {{multi}} RPC. This causes an error that looks 
> like:
> {noformat}
> [WARN] Coding error, see method javadoc. row=[B@1673eff, tableName=null
> {noformat}
> HBASE-15221 should fix HTableMultiplexer, but it would be good to push the 
> fix down into AsyncProcess instead of using higher-level workarounds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

[Heng Chen (JIRA)]

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

Heng Chen updated HBASE-15169:
--
Resolution: Fixed
Status: Resolved  (was: Patch Available)

push to branch-1.1

> Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to 
> branch-1.1
> -
>
> Key: HBASE-15169
> URL: https://issues.apache.org/jira/browse/HBASE-15169
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 1.1.4
>
> Attachments: HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch
>
>
> This one fails consistently for me and there's a fix hanging out upstream. 
> Let's bring it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (HBASE-15308) Flakey TestSplitWalDataLoss on branch-1.1

[Heng Chen (JIRA)]

Heng Chen created HBASE-15308:
-

 Summary: Flakey TestSplitWalDataLoss on branch-1.1
 Key: HBASE-15308
 URL: https://issues.apache.org/jira/browse/HBASE-15308
 Project: HBase
  Issue Type: Sub-task
Reporter: Heng Chen


It happens during HBASE-15169 QA test,  see 

https://builds.apache.org/job/PreCommit-HBASE-Build/628/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt

https://builds.apache.org/job/PreCommit-HBASE-Build/547/artifact/patchprocess/patch-unit-hbase-server-jdk1.8.0_72.txt



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

[Heng Chen (JIRA)]

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

Heng Chen commented on HBASE-15169:
---

still not run.   I will commit it,  the testcase has passed locally,  and 
javadoc failure has no relates with TestWALProcedureStoreOnHDFS.java

I will open another issue to see why 
hadoop.hbase.regionserver.TestSplitWalDataLoss failed,  it failed twice during 
this issue's QA tests.

Thanks [~stack]



> Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to 
> branch-1.1
> -
>
> Key: HBASE-15169
> URL: https://issues.apache.org/jira/browse/HBASE-15169
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 1.1.4
>
> Attachments: HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch
>
>
> This one fails consistently for me and there's a fix hanging out upstream. 
> Let's bring it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15295) MutateTableAccess.multiMutate() does not get high priority causing a deadlock

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15295:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 10 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
0s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 0m 59s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
13s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 2m 
43s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 4s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 25s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 23s 
{color} | {color:red} hbase-server in the patch failed with JDK v1.8.0_72. 
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 23s {color} 
| {color:red} hbase-server in the patch failed with JDK v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} compile {color} | {color:red} 0m 25s 
{color} | {color:red} hbase-server in the patch failed with JDK v1.7.0_95. 
{color} |
| {color:red}-1{color} | {color:red} javac {color} | {color:red} 0m 25s {color} 
| {color:red} hbase-server in the patch failed with JDK v1.7.0_95. {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 51s 
{color} | {color:red} Patch generated 60 new checkstyle issues in hbase-client 
(total was 507, now 565). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
40s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 0m 57s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.4.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 1m 49s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.4.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 2m 42s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.5.0. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 3m 34s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.5.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 4m 30s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.5.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 5m 24s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.6.1. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 6m 18s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.6.2. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 7m 11s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.6.3. {color} |
| {color:red}-1{color} | {color:red} hadoopcheck {color} | {color:red} 8m 4s 
{color} | {color:red} Patch causes 17 errors with Hadoop v2.7.1. {color} |
| {color:red}-1{color} | {color:red} findbugs {color} | {color:red} 0m 20s 
{color} | {color:red} hbase-server in the patch failed. {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 46s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |

[jira] [Commented] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family

[Sean Busbey (JIRA)]

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

Sean Busbey commented on HBASE-15130:
-

sorry was on vacation. build kicked off: 
https://builds.apache.org/view/PreCommit%20Builds/job/PreCommit-HBASE-Build/637/

> Backport 0.98 Scan different TimeRange for each column family 
> --
>
> Key: HBASE-15130
> URL: https://issues.apache.org/jira/browse/HBASE-15130
> Project: HBase
>  Issue Type: Bug
>  Components: Client, regionserver, Scanners
>Affects Versions: 0.98.17
>Reporter: churro morales
>Assignee: churro morales
> Fix For: 0.98.18
>
> Attachments: HBASE-15130-0.98.patch, HBASE-15130-0.98.v1.patch, 
> HBASE-15130-0.98.v1.patch, HBASE-15130-0.98.v2.patch, 
> HBASE-15130-0.98.v3.patch
>
>
> branch 98 version backport for HBASE-14355



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15130) Backport 0.98 Scan different TimeRange for each column family

[Andrew Purtell (JIRA)]

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

Andrew Purtell commented on HBASE-15130:


Let me test this locally and commit tonight if good. If [~busbey] has a chance 
to look at the Jenkins config in the meantime I'll hold off.


> Backport 0.98 Scan different TimeRange for each column family 
> --
>
> Key: HBASE-15130
> URL: https://issues.apache.org/jira/browse/HBASE-15130
> Project: HBase
>  Issue Type: Bug
>  Components: Client, regionserver, Scanners
>Affects Versions: 0.98.17
>Reporter: churro morales
>Assignee: churro morales
> Fix For: 0.98.18
>
> Attachments: HBASE-15130-0.98.patch, HBASE-15130-0.98.v1.patch, 
> HBASE-15130-0.98.v1.patch, HBASE-15130-0.98.v2.patch, 
> HBASE-15130-0.98.v3.patch
>
>
> branch 98 version backport for HBASE-14355



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15300) Upgrade to zookeeper 3.4.8

[Andrew Purtell (JIRA)]

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

Andrew Purtell commented on HBASE-15300:


I'm a bit shy about doing this right away after having had to back out an 
upgrade to zookeeper 3.4.7. They ended up pulling that release and going so far 
as to nuke release binaries from the mirrors. Can we do this on trunk only? 

> Upgrade to zookeeper 3.4.8
> --
>
> Key: HBASE-15300
> URL: https://issues.apache.org/jira/browse/HBASE-15300
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>Priority: Minor
>
> zookeeper 3.4.8 has been released.
> Among the fixes the following are desirable:
> ZOOKEEPER-706 large numbers of watches can cause session re-establishment to 
> fail 
> ZOOKEEPER-1797 PurgeTxnLog may delete data logs during roll
> This issue upgrades zookeeper dependency to 3.4.8



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15232) Exceptions returned over multi RPC don't automatically trigger region location reloads

[stack (JIRA)]

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

stack updated HBASE-15232:
--
Attachment: HBASE-15232.002.patch

Retry

> Exceptions returned over multi RPC don't automatically trigger region 
> location reloads
> --
>
> Key: HBASE-15232
> URL: https://issues.apache.org/jira/browse/HBASE-15232
> Project: HBase
>  Issue Type: Sub-task
>  Components: Client
>Reporter: Josh Elser
>Assignee: Josh Elser
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: HBASE-15232.001.patch, HBASE-15232.002.patch, 
> HBASE-15232.002.patch
>
>
> Follow-on for HBASE-15221:
> A work-around was added in HTableMultiplexer to work around an issue that 
> AsyncProcess wasn't clearing the region location cache on Exception. This was 
> stemming from the issue that the {{tableName}} is {{null}} because 
> HTableMultiplexer is using the {{multi}} RPC. This causes an error that looks 
> like:
> {noformat}
> [WARN] Coding error, see method javadoc. row=[B@1673eff, tableName=null
> {noformat}
> HBASE-15221 should fix HTableMultiplexer, but it would be good to push the 
> fix down into AsyncProcess instead of using higher-level workarounds.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15307) TestFailedAppendAndSync.testLockupAroundBadAssignSync is flakey

[stack (JIRA)]

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

stack updated HBASE-15307:
--
   Assignee: stack
Component/s: test
 flakey

> TestFailedAppendAndSync.testLockupAroundBadAssignSync is flakey
> ---
>
> Key: HBASE-15307
> URL: https://issues.apache.org/jira/browse/HBASE-15307
> Project: HBase
>  Issue Type: Sub-task
>  Components: flakey, test
>Reporter: stack
>Assignee: stack
>
> {code}
> Error Message
> test timed out after 30 milliseconds
> Stacktrace
> org.junit.runners.model.TestTimedOutException: test timed out after 30 
> milliseconds
>   at java.lang.Thread.sleep(Native Method)
>   at org.apache.hadoop.hbase.util.Threads.sleep(Threads.java:148)
>   at 
> org.apache.hadoop.hbase.regionserver.TestFailedAppendAndSync.testLockupAroundBadAssignSync(TestFailedAppendAndSync.java:242)
> Standard Output
> 2016-02-22 18:14:09,154 INFO  [main] hbase.ResourceChecker(148): before: 
> regionserver.TestFailedAppendAndSync#testLockupAroundBadAssignSync Thread=4, 
> OpenFileDescriptor=206, MaxFileDescriptor=6, SystemLoadAverage=1043, 
> ProcessCount=300, AvailableMemoryMB=1709
> 2016-02-22 18:14:09,809 DEBUG [main] hbase.HBaseTestingUtility(338): Setting 
> hbase.rootdir to 
> /home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533
> 2016-02-22 18:14:10,167 WARN  [Time-limited test] util.NativeCodeLoader(62): 
> Unable to load native-hadoop library for your platform... using builtin-java 
> classes where applicable
> 2016-02-22 18:14:10,452 INFO  [Time-limited test] wal.FSHLog(527): WAL 
> configuration: blocksize=32 MB, rollsize=30.40 MB, prefix=wal, suffix=, 
> logDir=/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/testLockupAroundBadAssignSync,
>  
> archiveDir=/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/oldWALs
> 2016-02-22 18:14:10,534 INFO  [Time-limited test] wal.FSHLog(874): New WAL 
> /home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/testLockupAroundBadAssignSync/wal.1456164850475
> 2016-02-22 18:14:10,673 INFO  [Time-limited test] regionserver.HRegion(6118): 
> creating HRegion testLockupAroundBadAssignSync HTD == 
> 'testLockupAroundBadAssignSync', {TABLE_ATTRIBUTES => {DURABILITY => 
> 'SYNC_WAL', READONLY => 'false'}, {NAME => 'MyCF', BLOOMFILTER => 'ROW', 
> VERSIONS => '2147483647', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 
> 'FALSE', DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 
> 'NONE', MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', 
> REPLICATION_SCOPE => '0'} RootDir = 
> /home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533
>  Table name == testLockupAroundBadAssignSync
> 2016-02-22 18:14:10,950 DEBUG [Time-limited test] regionserver.HRegion(718): 
> Instantiated 
> testLockupAroundBadAssignSync,,1456164850613.7eee51a40e497870a49a2965af62a054.
> 2016-02-22 18:14:11,253 INFO  
> [StoreOpener-7eee51a40e497870a49a2965af62a054-1] hfile.CacheConfig(292): 
> CacheConfig:disabled
> 2016-02-22 18:14:11,265 INFO  
> [StoreOpener-7eee51a40e497870a49a2965af62a054-1] 
> compactions.CompactionConfiguration(107): size [134217728, 
> 9223372036854775807, 9223372036854775807); files [3, 10); ratio 1.20; 
> off-peak ratio 5.00; throttle point 2684354560; major period 60480, 
> major jitter 0.50, min locality to compact 0.00
> 2016-02-22 18:14:11,269 DEBUG 
> [StoreOpener-7eee51a40e497870a49a2965af62a054-1] 
> regionserver.HRegionFileSystem(202): No StoreFiles for: 
> /home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/data/default/testLockupAroundBadAssignSync/7eee51a40e497870a49a2965af62a054/MyCF
> 2016-02-22 18:14:11,303 DEBUG [Time-limited test] regionserver.HRegion(3838): 
> Found 0 recovered edits file(s) under 
> /home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/data/default/testLockupAroundBadAssignSync/7eee51a40e497870a49a2965af62a054
> 2016-02-22 18:14:11,337 DEBUG [Time-limited test] 

[jira] [Created] (HBASE-15307) TestFailedAppendAndSync.testLockupAroundBadAssignSync is flakey

[stack (JIRA)]

stack created HBASE-15307:
-

 Summary: TestFailedAppendAndSync.testLockupAroundBadAssignSync is 
flakey
 Key: HBASE-15307
 URL: https://issues.apache.org/jira/browse/HBASE-15307
 Project: HBase
  Issue Type: Sub-task
Reporter: stack


{code}
Error Message

test timed out after 30 milliseconds
Stacktrace

org.junit.runners.model.TestTimedOutException: test timed out after 30 
milliseconds
at java.lang.Thread.sleep(Native Method)
at org.apache.hadoop.hbase.util.Threads.sleep(Threads.java:148)
at 
org.apache.hadoop.hbase.regionserver.TestFailedAppendAndSync.testLockupAroundBadAssignSync(TestFailedAppendAndSync.java:242)
Standard Output

2016-02-22 18:14:09,154 INFO  [main] hbase.ResourceChecker(148): before: 
regionserver.TestFailedAppendAndSync#testLockupAroundBadAssignSync Thread=4, 
OpenFileDescriptor=206, MaxFileDescriptor=6, SystemLoadAverage=1043, 
ProcessCount=300, AvailableMemoryMB=1709
2016-02-22 18:14:09,809 DEBUG [main] hbase.HBaseTestingUtility(338): Setting 
hbase.rootdir to 
/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533
2016-02-22 18:14:10,167 WARN  [Time-limited test] util.NativeCodeLoader(62): 
Unable to load native-hadoop library for your platform... using builtin-java 
classes where applicable
2016-02-22 18:14:10,452 INFO  [Time-limited test] wal.FSHLog(527): WAL 
configuration: blocksize=32 MB, rollsize=30.40 MB, prefix=wal, suffix=, 
logDir=/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/testLockupAroundBadAssignSync,
 
archiveDir=/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/oldWALs
2016-02-22 18:14:10,534 INFO  [Time-limited test] wal.FSHLog(874): New WAL 
/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/TestHRegiontestLockupAroundBadAssignSync/testLockupAroundBadAssignSync/wal.1456164850475
2016-02-22 18:14:10,673 INFO  [Time-limited test] regionserver.HRegion(6118): 
creating HRegion testLockupAroundBadAssignSync HTD == 
'testLockupAroundBadAssignSync', {TABLE_ATTRIBUTES => {DURABILITY => 
'SYNC_WAL', READONLY => 'false'}, {NAME => 'MyCF', BLOOMFILTER => 'ROW', 
VERSIONS => '2147483647', IN_MEMORY => 'false', KEEP_DELETED_CELLS => 'FALSE', 
DATA_BLOCK_ENCODING => 'NONE', TTL => 'FOREVER', COMPRESSION => 'NONE', 
MIN_VERSIONS => '0', BLOCKCACHE => 'true', BLOCKSIZE => '65536', 
REPLICATION_SCOPE => '0'} RootDir = 
/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533
 Table name == testLockupAroundBadAssignSync
2016-02-22 18:14:10,950 DEBUG [Time-limited test] regionserver.HRegion(718): 
Instantiated 
testLockupAroundBadAssignSync,,1456164850613.7eee51a40e497870a49a2965af62a054.
2016-02-22 18:14:11,253 INFO  [StoreOpener-7eee51a40e497870a49a2965af62a054-1] 
hfile.CacheConfig(292): CacheConfig:disabled
2016-02-22 18:14:11,265 INFO  [StoreOpener-7eee51a40e497870a49a2965af62a054-1] 
compactions.CompactionConfiguration(107): size [134217728, 9223372036854775807, 
9223372036854775807); files [3, 10); ratio 1.20; off-peak ratio 5.00; 
throttle point 2684354560; major period 60480, major jitter 0.50, min 
locality to compact 0.00
2016-02-22 18:14:11,269 DEBUG [StoreOpener-7eee51a40e497870a49a2965af62a054-1] 
regionserver.HRegionFileSystem(202): No StoreFiles for: 
/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/data/default/testLockupAroundBadAssignSync/7eee51a40e497870a49a2965af62a054/MyCF
2016-02-22 18:14:11,303 DEBUG [Time-limited test] regionserver.HRegion(3838): 
Found 0 recovered edits file(s) under 
/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/data/default/testLockupAroundBadAssignSync/7eee51a40e497870a49a2965af62a054
2016-02-22 18:14:11,337 DEBUG [Time-limited test] wal.WALSplitter(729): Wrote 
region 
seqId=/home/jenkins/jenkins-slave/workspace/HBase-Trunk_matrix/jdk/latest1.8/label/yahoo-not-h2/hbase-server/target/test-data/892bb23a-6932-4631-b4e0-a6384423d533/data/default/testLockupAroundBadAssignSync/7eee51a40e497870a49a2965af62a054/recovered.edits/2.seqid
 to file, newSeqId=2, maxSeqId=0
2016-02-22 18:14:11,338 INFO  [Time-limited test] regionserver.HRegion(853): 
Onlined 

[jira] [Updated] (HBASE-15295) MutateTableAccess.multiMutate() does not get high priority causing a deadlock

[Enis Soztutar (JIRA)]

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

Enis Soztutar updated HBASE-15295:
--
Attachment: hbase-15295_v1.patch

reattach for hadoopqa. 

> MutateTableAccess.multiMutate() does not get high priority causing a deadlock
> -
>
> Key: HBASE-15295
> URL: https://issues.apache.org/jira/browse/HBASE-15295
> Project: HBase
>  Issue Type: Bug
>Reporter: Enis Soztutar
>Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.3.0, 1.2.1, 1.1.4
>
> Attachments: hbase-15295_v1.patch, hbase-15295_v1.patch
>
>
> We have seen this in a cluster with Phoenix secondary indexes leading to a 
> deadlock. All handlers are busy waiting on the index updates to finish:
> {code}
> "B.defaultRpcServer.handler=50,queue=0,port=16020" #91 daemon prio=5 
> os_prio=0 tid=0x7f29f64ba000 nid=0xab51 waiting on condition 
> [0x7f29a8762000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   - parking to wait for  <0x000124f1d5c8> (a 
> com.google.common.util.concurrent.AbstractFuture$Sync)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
>   at 
> com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:275)
>   at 
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:111)
>   at 
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submit(BaseTaskRunner.java:66)
>   at 
> org.apache.phoenix.hbase.index.parallel.BaseTaskRunner.submitUninterruptible(BaseTaskRunner.java:99)
>   at 
> org.apache.phoenix.hbase.index.write.ParallelWriterIndexCommitter.write(ParallelWriterIndexCommitter.java:194)
>   at 
> org.apache.phoenix.hbase.index.write.IndexWriter.write(IndexWriter.java:179)
>   at 
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:144)
>   at 
> org.apache.phoenix.hbase.index.write.IndexWriter.writeAndKillYourselfOnFailure(IndexWriter.java:134)
>   at 
> org.apache.phoenix.hbase.index.Indexer.doPostWithExceptions(Indexer.java:457)
>   at org.apache.phoenix.hbase.index.Indexer.doPost(Indexer.java:406)
>   at 
> org.apache.phoenix.hbase.index.Indexer.postBatchMutate(Indexer.java:401)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$36.call(RegionCoprocessorHost.java:1006)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1673)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1748)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1705)
>   at 
> org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.postBatchMutate(RegionCoprocessorHost.java:1002)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:3162)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2801)
>   at 
> org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2743)
>   at 
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doBatchOp(RSRpcServices.java:692)
>   at 
> org.apache.hadoop.hbase.regionserver.RSRpcServices.doNonAtomicRegionMutation(RSRpcServices.java:654)
>   at 
> org.apache.hadoop.hbase.regionserver.RSRpcServices.multi(RSRpcServices.java:2031)
>   at 
> org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:32213)
>   at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2114)
>   at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:101)
>   at 
> org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)
>   at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)
>   at java.lang.Thread.run(Thread.java:745)
> {code}
> And the index region is trying to split, and is trying to do a meta update: 
> {code}
> "regionserver//10.132.70.191:16020-splits-1454693389669" #1779 
> prio=5 os_prio=0 tid=0x7f29e149c000 nid=0x5107 in Object.wait() 
> [0x7f1f136d6000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at 
> 

[jira] [Commented] (HBASE-15298) Fix missing or wrong asciidoc anchors in the reference guide

[Hudson (JIRA)]

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

Hudson commented on HBASE-15298:


FAILURE: Integrated in HBase-Trunk_matrix #727 (See 
[https://builds.apache.org/job/HBase-Trunk_matrix/727/])
HBASE-15298 Fix missing or wrong asciidoc anchors in the reference guide 
(mstanleyjones: rev 2966eee60293c49e6cae821e736716b70db108e7)
* src/main/asciidoc/_chapters/preface.adoc
* src/main/asciidoc/_chapters/ops_mgt.adoc
* src/main/asciidoc/_chapters/ycsb.adoc
* src/main/asciidoc/_chapters/unit_testing.adoc
* src/main/asciidoc/_chapters/compression.adoc
* src/main/asciidoc/_chapters/performance.adoc
* src/main/asciidoc/_chapters/security.adoc
* src/main/asciidoc/_chapters/architecture.adoc
* src/main/asciidoc/_chapters/troubleshooting.adoc
* src/main/asciidoc/_chapters/datamodel.adoc
* src/main/asciidoc/_chapters/zookeeper.adoc
* src/main/asciidoc/_chapters/developer.adoc
* src/main/asciidoc/_chapters/configuration.adoc
* src/main/asciidoc/_chapters/faq.adoc
* src/main/asciidoc/_chapters/cp.adoc
* src/main/asciidoc/_chapters/schema_design.adoc
* src/main/asciidoc/_chapters/appendix_contributing_to_documentation.adoc


> Fix missing or wrong asciidoc anchors in the reference guide
> 
>
> Key: HBASE-15298
> URL: https://issues.apache.org/jira/browse/HBASE-15298
> Project: HBase
>  Issue Type: Bug
>  Components: documentation
>Reporter: Youngjoon Kim
>Assignee: Youngjoon Kim
>Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15298.patch
>
>
> There are some missing or wrong asciidoc anchors in the reference guide.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15222:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
20s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 6s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 10s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 5m 
45s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
46s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
33s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 7s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 16s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 11s 
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 9s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 9s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 15s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 9s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-common 
(total was 1, now 1). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 16s 
{color} | {color:red} Patch generated 8 new checkstyle issues in 
hbase-hadoop2-compat (total was 67, now 53). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 8s 
{color} | {color:red} Patch generated 4 new checkstyle issues in hbase-server 
(total was 194, now 195). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
45s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 0s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
28m 6s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 
29s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 12s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 23s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 43s {color} 
| {color:red} hbase-common in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 19s 
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 16s 
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | 

[jira] [Resolved] (HBASE-15299) Getting Error when starting minicluster --java.lang.NoSuchMethodError: org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster()Lorg/apache/hadoop/hbase/MiniHBaseC

[stack (JIRA)]

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

stack resolved HBASE-15299.
---
Resolution: Invalid

Please ask on the mailing list before filing an issue. Provide more detail on 
your environment while you are at it. Thanks.

> Getting Error when starting minicluster --java.lang.NoSuchMethodError: 
> org.apache.hadoop.hbase.HBaseTestingUtility.startMiniCluster()Lorg/apache/hadoop/hbase/MiniHBaseCluster;
> ---
>
> Key: HBASE-15299
> URL: https://issues.apache.org/jira/browse/HBASE-15299
> Project: HBase
>  Issue Type: Bug
>Reporter: bandhu Gupta
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15222) Use less contended classes for metrics

[Hadoop QA (JIRA)]

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

Hadoop QA commented on HBASE-15222:
---

| (x) *{color:red}-1 overall{color}* |
\\
\\
|| Vote || Subsystem || Runtime || Comment ||
| {color:blue}0{color} | {color:blue} reexec {color} | {color:blue} 0m 0s 
{color} | {color:blue} Docker mode activated. {color} |
| {color:green}+1{color} | {color:green} hbaseanti {color} | {color:green} 0m 
0s {color} | {color:green} Patch does not have any anti-patterns. {color} |
| {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s 
{color} | {color:green} The patch does not contain any @author tags. {color} |
| {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 
0s {color} | {color:green} The patch appears to include 2 new or modified test 
files. {color} |
| {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 3m 
7s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 12s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 6m 
3s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
50s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 
38s {color} | {color:green} master passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 10s 
{color} | {color:green} master passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 25s 
{color} | {color:green} master passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} mvninstall {color} | {color:red} 0m 12s 
{color} | {color:red} hbase-hadoop2-compat in the patch failed. {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 15s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 15s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 17s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 17s 
{color} | {color:green} the patch passed {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 1m 16s 
{color} | {color:red} Patch generated 1 new checkstyle issues in hbase-common 
(total was 1, now 1). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 0m 16s 
{color} | {color:red} Patch generated 8 new checkstyle issues in 
hbase-hadoop2-compat (total was 67, now 53). {color} |
| {color:red}-1{color} | {color:red} checkstyle {color} | {color:red} 4m 16s 
{color} | {color:red} Patch generated 4 new checkstyle issues in hbase-server 
(total was 194, now 195). {color} |
| {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 
51s {color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 
0s {color} | {color:green} Patch has no whitespace issues. {color} |
| {color:green}+1{color} | {color:green} xml {color} | {color:green} 0m 1s 
{color} | {color:green} The patch has no ill-formed XML file. {color} |
| {color:green}+1{color} | {color:green} hadoopcheck {color} | {color:green} 
27m 1s {color} | {color:green} Patch does not cause any errors with Hadoop 
2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.1 2.6.2 2.6.3 2.7.1. {color} |
| {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 4m 6s 
{color} | {color:green} the patch passed {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 5s 
{color} | {color:green} the patch passed with JDK v1.8.0_72 {color} |
| {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 17s 
{color} | {color:green} the patch passed with JDK v1.7.0_95 {color} |
| {color:red}-1{color} | {color:red} unit {color} | {color:red} 1m 46s {color} 
| {color:red} hbase-common in the patch failed with JDK v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 21s 
{color} | {color:green} hbase-hadoop2-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:green}+1{color} | {color:green} unit {color} | {color:green} 0m 17s 
{color} | {color:green} hbase-hadoop-compat in the patch passed with JDK 
v1.8.0_72. {color} |
| {color:red}-1{color} | {color:red} unit {color} | 

[jira] [Commented] (HBASE-15301) Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS method signature

[stack (JIRA)]

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

stack commented on HBASE-15301:
---

Nice. What versions does this apply to [~carp84]? Thanks.

> Remove the never-thrown NamingException from TableInputFormatBase#reverseDNS 
> method signature
> -
>
> Key: HBASE-15301
> URL: https://issues.apache.org/jira/browse/HBASE-15301
> Project: HBase
>  Issue Type: Improvement
>Reporter: Yu Li
>Assignee: Yu Li
>Priority: Minor
> Attachments: HBASE-15301.patch
>
>
> When fixing HBASE-15185, I found that after HBASE-12115 NamingException is 
> handled inside {{TableInputFormatBase#reverseDNS}}, and we should remove it 
> from the throws declaration



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-14918) In-Memory MemStore Flush and Compaction

[stack (JIRA)]

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

stack commented on HBASE-14918:
---

Sounds great Anastasia.

bq. The HFile instance (with all its great possibilities) seams like something 
too complex for this simple task of storing the data flat.

Agree.

You looked at CellBlocks?

Allocations offheap take time. You looked at bytebufferpool?  Could allocate a 
bunch up front and then do reuse?



> In-Memory MemStore Flush and Compaction
> ---
>
> Key: HBASE-14918
> URL: https://issues.apache.org/jira/browse/HBASE-14918
> Project: HBase
>  Issue Type: Umbrella
>Affects Versions: 2.0.0
>Reporter: Eshcar Hillel
>Assignee: Eshcar Hillel
> Fix For: 0.98.18
>
> Attachments: CellBlocksSegmentDesign.pdf, MSLABMove.patch
>
>
> A memstore serves as the in-memory component of a store unit, absorbing all 
> updates to the store. From time to time these updates are flushed to a file 
> on disk, where they are compacted (by eliminating redundancies) and 
> compressed (i.e., written in a compressed format to reduce their storage 
> size).
> We aim to speed up data access, and therefore suggest to apply in-memory 
> memstore flush. That is to flush the active in-memory segment into an 
> intermediate buffer where it can be accessed by the application. Data in the 
> buffer is subject to compaction and can be stored in any format that allows 
> it to take up smaller space in RAM. The less space the buffer consumes the 
> longer it can reside in memory before data is flushed to disk, resulting in 
> better performance.
> Specifically, the optimization is beneficial for workloads with 
> medium-to-high key churn which incur many redundant cells, like persistent 
> messaging. 
> We suggest to structure the solution as 4 subtasks (respectively, patches). 
> (1) Infrastructure - refactoring of the MemStore hierarchy, introducing 
> segment (StoreSegment) as first-class citizen, and decoupling memstore 
> scanner from the memstore implementation;
> (2) Adding StoreServices facility at the region level to allow memstores 
> update region counters and access region level synchronization mechanism;
> (3) Implementation of a new memstore (CompactingMemstore) with non-optimized 
> immutable segment representation, and 
> (4) Memory optimization including compressed format representation and off 
> heap allocations.
> This Jira continues the discussion in HBASE-13408.
> Design documents, evaluation results and previous patches can be found in 
> HBASE-13408. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15302) Reenable the other tests disabled by HBASE-14678

[stack (JIRA)]

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

stack updated HBASE-15302:
--
Attachment: HBASE-15302-v1.txt

Retry to see if any zombies in here.

You good w/ a commit on this [~Apache9]?

> Reenable the other tests disabled by HBASE-14678
> 
>
> Key: HBASE-15302
> URL: https://issues.apache.org/jira/browse/HBASE-15302
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Phil Yang
>Assignee: Phil Yang
> Fix For: 2.0.0, 1.3.0, 1.2.1
>
> Attachments: HBASE-15302-v1.txt, HBASE-15302-v1.txt
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15169) Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to branch-1.1

[stack (JIRA)]

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

stack commented on HBASE-15169:
---

Go for it [~chenheng] What is that javadoc failure for 1.8 about? Fix on commit?

> Backport HBASE-14362 'TestWALProcedureStoreOnHDFS is super duper flaky' to 
> branch-1.1
> -
>
> Key: HBASE-15169
> URL: https://issues.apache.org/jira/browse/HBASE-15169
> Project: HBase
>  Issue Type: Sub-task
>  Components: test
>Reporter: Nick Dimiduk
>Assignee: Heng Chen
>Priority: Critical
> Fix For: 1.1.4
>
> Attachments: HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch, HBASE-15169-branch-1.1.patch, 
> HBASE-15169-branch-1.1.patch
>
>
> This one fails consistently for me and there's a fix hanging out upstream. 
> Let's bring it back.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Attachment: HBASE-15306-v1.patch

first patch, same as one RB

> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15306-v1.patch
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Status: Patch Available  (was: Open)

> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15306-v1.patch
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (HBASE-15243) Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList return SEEK_NEXT_USING_HINT

[Ted Yu (JIRA)]

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

Ted Yu commented on HBASE-15243:


Patch v5 should be good to go.

> Utilize the lowest seek value when all Filters in MUST_PASS_ONE FilterList 
> return SEEK_NEXT_USING_HINT
> --
>
> Key: HBASE-15243
> URL: https://issues.apache.org/jira/browse/HBASE-15243
> Project: HBase
>  Issue Type: Improvement
>Reporter: Ted Yu
>Assignee: Ted Yu
> Fix For: 2.0.0, 1.3.0
>
> Attachments: HBASE-15243-v1.txt, HBASE-15243-v2.txt, 
> HBASE-15243-v3.txt, HBASE-15243-v4.txt, HBASE-15243-v5.txt
>
>
> As Preston Koprivica pointed out at the tail of HBASE-4394, when all filters 
> in a MUST_PASS_ONE FilterList return a SEEK_USING_NEXT_HINT code, we should 
> return SEEK_NEXT_USING_HINT from the FilterList to utilize the lowest seek 
> value.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Description: 
Sometimes it's useful to be able to modify call queue size on prod cluster 
without having to do a rolling restart. 

Here setting fixed hard limit on call queue size and soft limit which is 
dynamically-updatable.

https://reviews.facebook.net/D54579 for review, will test more.

  was:
Sometimes it's useful to be able to modify call queue size on prod cluster 
without having to do a rolling restart. 

Here setting fixed hard limit on call queue size and soft limit which is 
dynamically-updatable.

https://reviews.facebook.net/D54579


> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579 for review, will test more.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (HBASE-15306) Make RPC call queue length dynamically configurable

[Mikhail Antonov (JIRA)]

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

Mikhail Antonov updated HBASE-15306:

Description: 
Sometimes it's useful to be able to modify call queue size on prod cluster 
without having to do a rolling restart. 

Here setting fixed hard limit on call queue size and soft limit which is 
dynamically-updatable.

https://reviews.facebook.net/D54579

  was:
Sometimes it's useful to be able to modify call queue size on prod cluster 
without having to do a rolling restart. 

Here setting fixed hard limit on call queue size and soft limit which is 
dynamically-updatable.


> Make RPC call queue length dynamically configurable
> ---
>
> Key: HBASE-15306
> URL: https://issues.apache.org/jira/browse/HBASE-15306
> Project: HBase
>  Issue Type: Improvement
>  Components: IPC/RPC
>Affects Versions: 1.2.0
>Reporter: Mikhail Antonov
>Assignee: Mikhail Antonov
> Fix For: 2.0.0, 1.3.0
>
>
> Sometimes it's useful to be able to modify call queue size on prod cluster 
> without having to do a rolling restart. 
> Here setting fixed hard limit on call queue size and soft limit which is 
> dynamically-updatable.
> https://reviews.facebook.net/D54579



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)