date:20150417


[ 
https://issues.apache.org/jira/browse/HBASE-13487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499186#comment-14499186
 ] 

Anoop Sam John commented on HBASE-13487:


+1
Like that explanation with eg: shell commands and its output. Great.


 Doc KEEP_DELETED_CELLS
 --

 Key: HBASE-13487
 URL: https://issues.apache.org/jira/browse/HBASE-13487
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: stack
Assignee: stack
 Attachments: 13487.txt


 Let me doc this nice feature that has been around a long time but is not 
 explained other than in Lars lectures. I was talking to someone and could not 
 explain this feature myself until Lars set me straight.



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

[jira] [Commented] (HBASE-13473) deleted cells come back alive after the stripe compaction


[ 
https://issues.apache.org/jira/browse/HBASE-13473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499043#comment-14499043
 ] 

Hudson commented on HBASE-13473:


FAILURE: Integrated in HBase-0.98 #951 (See 
[https://builds.apache.org/job/HBase-0.98/951/])
HBASE-13473 deleted cells come back alive after the stripe compaction (jeongmin 
kim) (tedyu: rev a09d3ccb709ae72c066eabac1c05f0c6f39679d6)
* 
hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/compactions/TestStripeCompactionPolicy.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/StripeCompactionPolicy.java


 deleted cells come back alive after the stripe compaction
 -

 Key: HBASE-13473
 URL: https://issues.apache.org/jira/browse/HBASE-13473
 Project: HBase
  Issue Type: Bug
  Components: Compaction
Affects Versions: 2.0.0, 1.0.1, 1.1.0, 0.98.12
Reporter: jeongmin kim
Assignee: jeongmin kim
Priority: Blocker
  Labels: patch
 Fix For: 2.0.0, 1.0.1, 1.1.0, 0.98.13

 Attachments: HBASE-13473.patch, HBASE_13473-v2.patch


 during the STRIPE compaction,
 deletes(tombstones) are being dropped in 2 cases.
 1. Compaction including L0  (includeL0 == true)
 2. L0 has no files (canDropDeletesWithoutL0 == true)
 To drop delete marker and keep the consistency during compaction, 
 All of HFiles in the stripe has to be selected, just like major compaction.
 otherwise, after the compaction only delete markers would be gone, 
 and deleted cells (which is in the not-selected HFiles) are going to be alive 
 again.
 In my cluster, there was no file on L0(canDropDeletesWithoutL0==true) and not 
 all files are selected for compaction, so some of deleted rows have come back 
 alive and appears when i get or scan after compactions.
 I made a patch about it.
 it checks if all files are selected before we set the majorRange of 
 compaction request .



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

[jira] [Commented] (HBASE-10944) Remove all kv.getBuffer() and kv.getRow() references existing in the code


[ 
https://issues.apache.org/jira/browse/HBASE-10944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499184#comment-14499184
 ] 

Anoop Sam John commented on HBASE-10944:


Most of the calls have gone away now by different commits.  HBASE-11425 will 
remove all from read path (am sure)
Will check once again other references and avoid them.

 Remove all kv.getBuffer() and kv.getRow() references existing in the code
 -

 Key: HBASE-10944
 URL: https://issues.apache.org/jira/browse/HBASE-10944
 Project: HBase
  Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
 Fix For: 2.0.0, 1.1.0


 kv.getRow() and kv.getBuffers() are still used in places to form key byte[] 
 and row byte[].  Removing all such instances including testcases will make 
 the usage of Cell complete.



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

[jira] [Created] (HBASE-13490) Linux Command execution is failing while starting HBase processes using hbase-daemon.sh file

2015-04-17 Thread Y. SREENIVASULU REDDY (JIRA)

Y. SREENIVASULU REDDY created HBASE-13490:
-

 Summary: Linux Command execution is failing while starting HBase 
processes using hbase-daemon.sh file
 Key: HBASE-13490
 URL: https://issues.apache.org/jira/browse/HBASE-13490
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 1.0.0
Reporter: Y. SREENIVASULU REDDY
Assignee: Y. SREENIVASULU REDDY
Priority: Minor
 Fix For: 2.0.0


While starting any HBase process (HMaster or Regionserver)
ulimit command execution is failing.

{code}
 echo `date` Starting $command on `hostname`  ${HBASE_LOGLOG}
`ulimit -a`  $HBASE_LOGLOG 21
{code}

Log message is follows.
{noformat}
Thu Apr 16 19:24:25 IST 2015 Starting regionserver on HOST-10
/opt/hdfsdata/HA/install/hbase/regionserver/bin/hbase-daemon.sh: line 207: 
core: command not found
{noformat}



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

[jira] [Updated] (HBASE-13456) Improve HFilePrettyPrinter first hbase:meta region processing

2015-04-17 Thread Samir Ahmic (JIRA)


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

Samir Ahmic updated HBASE-13456:

Status: Patch Available  (was: In Progress)

 Improve HFilePrettyPrinter first hbase:meta region processing 
 --

 Key: HBASE-13456
 URL: https://issues.apache.org/jira/browse/HBASE-13456
 Project: HBase
  Issue Type: Improvement
  Components: util
Affects Versions: 0.98.12, 2.0.0
 Environment: x86_64 GNU/Linux
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Priority: Minor
 Attachments: HBASE-13456-0.98-v2.patch, HBASE-13456-0.98.patch, 
 HBASE-13456-master-v2.patch, HBASE-13456-master.patch


 HFilePrettyPrinter have couple of small issues when -r option is used with 
 hbase:meta region as argument:
 1. Processing files in oldWals and recovered.edits directories
 {code}
 $ hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1
 Number of region files found - 3
 Found file[1] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Found file[2] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Found file[3] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 2015-04-13 14:08:21,461 ERROR [main] hfile.HFilePrettyPrinter: Error reading 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile 
 Trailer from file 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 {code}
 2. If full region name is passed as argument we have wrong encoded region 
 name returned:
 {code}
 hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1.1588230740
 region dir - hdfs://P3cluster/hbase/data/hbase/meta/104563571
 2015-04-13 14:21:43,012 INFO  [main] Configuration.deprecation: 
 hadoop.native.lib is deprecated. Instead, use io.native.lib.available
 2015-04-13 14:21:43,711 INFO  [main] util.ChecksumType: Checksum using 
 org.apache.hadoop.util.PureJavaCrc32
 2015-04-13 14:21:43,717 INFO  [main] util.ChecksumType: Checksum can use 
 org.apache.hadoop.util.PureJavaCrc32C
 2015-04-13 14:21:43,899 ERROR [main] hfile.HFilePrettyPrinter: Error parsing 
 command-line options
 java.io.FileNotFoundException: File 
 hdfs://P3cluster/hbase/data/hbase/meta/104563571 does not exist.
 {code}
 I have modified HFilePrettyPrinter.java to address this issues. Patch is 
 coming soon.



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

[jira] [Commented] (HBASE-13487) Doc KEEP_DELETED_CELLS

2015-04-17 Thread Ashish Singhi (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499294#comment-14499294
 ] 

Ashish Singhi commented on HBASE-13487:
---

Nice work.
+1 (non-binding)

 Doc KEEP_DELETED_CELLS
 --

 Key: HBASE-13487
 URL: https://issues.apache.org/jira/browse/HBASE-13487
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: stack
Assignee: stack
 Attachments: 13487.txt


 Let me doc this nice feature that has been around a long time but is not 
 explained other than in Lars lectures. I was talking to someone and could not 
 explain this feature myself until Lars set me straight.



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

[jira] [Updated] (HBASE-13490) Linux Command execution is failing while starting HBase processes using hbase-daemon.sh file

2015-04-17 Thread Y. SREENIVASULU REDDY (JIRA)


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

Y. SREENIVASULU REDDY updated HBASE-13490:
--
Attachment: HBASE-13490.patch

patch file attached.

 Linux Command execution is failing while starting HBase processes using 
 hbase-daemon.sh file
 

 Key: HBASE-13490
 URL: https://issues.apache.org/jira/browse/HBASE-13490
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 1.0.0
Reporter: Y. SREENIVASULU REDDY
Assignee: Y. SREENIVASULU REDDY
Priority: Minor
 Fix For: 2.0.0

 Attachments: HBASE-13490.patch


 While starting any HBase process (HMaster or Regionserver)
 ulimit command execution is failing.
 {code}
  echo `date` Starting $command on `hostname`  ${HBASE_LOGLOG}
 `ulimit -a`  $HBASE_LOGLOG 21
 {code}
 Log message is follows.
 {noformat}
 Thu Apr 16 19:24:25 IST 2015 Starting regionserver on HOST-10
 /opt/hdfsdata/HA/install/hbase/regionserver/bin/hbase-daemon.sh: line 207: 
 core: command not found
 {noformat}



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499333#comment-14499333
 ] 

Hadoop QA commented on HBASE-13351:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726057/HBASE-13351-v4.patch
  against master branch at commit 7fb6055ed7304b05a383a730b64e55e41772bcf8.
  ATTACHMENT ID: 12726057

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 20 new 
or modified tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

 {color:red}-1 core tests{color}.  The patch failed these unit tests:
 

 {color:red}-1 core zombie tests{color}.  There are 6 zombie test(s): 

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13729//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13729//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13729//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13729//console

This message is automatically generated.

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Updated] (HBASE-13490) Linux Command execution is failing while starting HBase processes using hbase-daemon.sh file

2015-04-17 Thread Y. SREENIVASULU REDDY (JIRA)


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

Y. SREENIVASULU REDDY updated HBASE-13490:
--
Status: Patch Available  (was: Open)

 Linux Command execution is failing while starting HBase processes using 
 hbase-daemon.sh file
 

 Key: HBASE-13490
 URL: https://issues.apache.org/jira/browse/HBASE-13490
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 1.0.0
Reporter: Y. SREENIVASULU REDDY
Assignee: Y. SREENIVASULU REDDY
Priority: Minor
 Fix For: 2.0.0

 Attachments: HBASE-13490.patch


 While starting any HBase process (HMaster or Regionserver)
 ulimit command execution is failing.
 {code}
  echo `date` Starting $command on `hostname`  ${HBASE_LOGLOG}
 `ulimit -a`  $HBASE_LOGLOG 21
 {code}
 Log message is follows.
 {noformat}
 Thu Apr 16 19:24:25 IST 2015 Starting regionserver on HOST-10
 /opt/hdfsdata/HA/install/hbase/regionserver/bin/hbase-daemon.sh: line 207: 
 core: command not found
 {noformat}



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

[jira] [Commented] (HBASE-13307) Making methods under ScannerV2#next inlineable, faster


[ 
https://issues.apache.org/jira/browse/HBASE-13307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499356#comment-14499356
 ] 

Hadoop QA commented on HBASE-13307:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726061/13307v7.txt
  against master branch at commit 7fb6055ed7304b05a383a730b64e55e41772bcf8.
  ATTACHMENT ID: 12726061

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13730//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13730//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13730//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13730//console

This message is automatically generated.

 Making methods under ScannerV2#next inlineable, faster
 --

 Key: HBASE-13307
 URL: https://issues.apache.org/jira/browse/HBASE-13307
 Project: HBase
  Issue Type: Sub-task
  Components: Scanners
Reporter: stack
Assignee: stack
 Fix For: 2.0.0, 1.1.0

 Attachments: 13307.txt, 13307v2.branch-1.txt, 13307v3.branch-1.txt, 
 13307v4.branch-1.txt, 13307v5.branch-1.txt, 13307v6.branch-1.txt, 
 13307v6.txt, 13307v7.txt, cpu.png, gc.png, next.png, traces.8.svg, 
 traces.9.svg


 See parent issue for patch and evidence.
 I was looking at graphs of our scan and found that methods were 'too big' to 
 be inlined (looking at jvm compilation and inlining output flags -- see 
 parent for list).  Changing method size helped some. Let me commit the 
 resultant patch.



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

[jira] [Updated] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


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

Anoop Sam John updated HBASE-13491:
---
Attachment: HBASE-13491.patch

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


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

Anoop Sam John updated HBASE-13491:
---
Status: Patch Available  (was: Open)

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13307) Making methods under ScannerV2#next inlineable, faster


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

stack updated HBASE-13307:
--
Attachment: 13307v7.txt

Failure unrelated but let me fix the checkstyle.

 Making methods under ScannerV2#next inlineable, faster
 --

 Key: HBASE-13307
 URL: https://issues.apache.org/jira/browse/HBASE-13307
 Project: HBase
  Issue Type: Sub-task
  Components: Scanners
Reporter: stack
Assignee: stack
 Fix For: 2.0.0, 1.1.0

 Attachments: 13307.txt, 13307v2.branch-1.txt, 13307v3.branch-1.txt, 
 13307v4.branch-1.txt, 13307v5.branch-1.txt, 13307v6.branch-1.txt, 
 13307v6.txt, 13307v7.txt, cpu.png, gc.png, next.png, traces.8.svg, 
 traces.9.svg


 See parent issue for patch and evidence.
 I was looking at graphs of our scan and found that methods were 'too big' to 
 be inlined (looking at jvm compilation and inlining output flags -- see 
 parent for list).  Changing method size helped some. Let me commit the 
 resultant patch.



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

[jira] [Created] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule

Anoop Sam John created HBASE-13491:
--

 Summary: Issue in FuzzyRowFilter#getNextForFuzzyRule
 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Reporter: Anoop Sam John
Assignee: Anoop Sam John


{code}
for (int i = 0; i  result.length; i++) {
  if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
result[i] = row[offset + i];
if (!order.isMax(row[i])) {
  // this is non-fixed position and is not at max value, hence we can 
increase it
  toInc = i;
}
  }
{code}
See we take row bytes with out considering the row offset.  The test cases are 
passing as we pass 0 offset row bytes. Change in the test will reveal the bug.

Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


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

Anoop Sam John updated HBASE-13491:
---
Affects Version/s: 1.0.0

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


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

Anoop Sam John updated HBASE-13491:
---
Fix Version/s: 1.2.0
   1.1.0
   1.0.1
   2.0.0

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13456) Improve HFilePrettyPrinter first hbase:meta region processing


[ 
https://issues.apache.org/jira/browse/HBASE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499473#comment-14499473
 ] 

Hadoop QA commented on HBASE-13456:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12725579/HBASE-13456-master-v2.patch
  against master branch at commit 7fb6055ed7304b05a383a730b64e55e41772bcf8.
  ATTACHMENT ID: 12725579

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:red}-1 tests included{color}.  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:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13731//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13731//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13731//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13731//console

This message is automatically generated.

 Improve HFilePrettyPrinter first hbase:meta region processing 
 --

 Key: HBASE-13456
 URL: https://issues.apache.org/jira/browse/HBASE-13456
 Project: HBase
  Issue Type: Improvement
  Components: util
Affects Versions: 2.0.0, 0.98.12
 Environment: x86_64 GNU/Linux
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Priority: Minor
 Attachments: HBASE-13456-0.98-v2.patch, HBASE-13456-0.98.patch, 
 HBASE-13456-master-v2.patch, HBASE-13456-master.patch


 HFilePrettyPrinter have couple of small issues when -r option is used with 
 hbase:meta region as argument:
 1. Processing files in oldWals and recovered.edits directories
 {code}
 $ hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1
 Number of region files found - 3
 Found file[1] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Found file[2] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Found file[3] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 2015-04-13 14:08:21,461 ERROR [main] hfile.HFilePrettyPrinter: Error reading 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile 
 Trailer from file 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 {code}
 2. If full region name is passed as argument we have wrong encoded region 
 name returned:
 {code}
 hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1.1588230740
 region dir - hdfs://P3cluster/hbase/data/hbase/meta/104563571
 2015-04-13 14:21:43,012 INFO  [main] Configuration.deprecation: 
 hadoop.native.lib is deprecated. Instead, use io.native.lib.available
 2015-04-13 14:21:43,711 INFO  [main] util.ChecksumType: Checksum using 
 org.apache.hadoop.util.PureJavaCrc32
 2015-04-13 14:21:43,717 INFO  [main] util.ChecksumType: Checksum can use 
 org.apache.hadoop.util.PureJavaCrc32C
 2015-04-13 14:21:43,899 ERROR [main]

[jira] [Commented] (HBASE-13260) Bootstrap Tables for fun and profit

2015-04-17 Thread Matteo Bertozzi (JIRA)

[
https://issues.apache.org/jira/browse/HBASE-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499474#comment-14499474
]

Matteo Bertozzi commented on HBASE-13260:
-

{quote}For assignment, the store might become the bottleneck, but in case of
fast procs, there will not be flushes for most of the time (since procs will
get deleted from memstore). So WAL is the bottleneck. Between the WAL format in
WALProcStore and the FSHLog, I did not check which one has more overhead vs
write speed. But both will have to go thru wal IO.{quote}
aside compactions, I don't think the perf problem me and stack raised is around
adding procs to the WAL, but it is on replay. With the current proc wal, we can
throw the wal away at any point if we know that all the procs are deleted or
all of them are in the latest wal. with the region wal as far as I know we have
to keep all the wals around until we have a flush. to with the region the wal
replay will be much more heavier. but maybe we can do some tricks there too.
e.g. if the memstore is empty after deletes roll the wal and archive the others

Bootstrap Tables for fun and profit

Key: HBASE-13260
URL: https://issues.apache.org/jira/browse/HBASE-13260
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 2.0.0, 1.1.0

Attachments: hbase-13260_prototype.patch

Over at the ProcV2 discussions(HBASE-12439) and elsewhere I was mentioning an
idea where we may want to use regular old regions to store/persist some data
needed for HBase master to operate.
We regularly use system tables for storing system data. acl, meta, namespace,
quota are some examples. We also store the table state in meta now. Some data
is persisted in zk only (replication peers and replication state, etc). We
are moving away from zk as a permanent storage. As any self-respecting
database does, we should store almost all of our data in HBase itself.
However, we have an availability dependency between different kinds of
data. For example all system tables need meta to be assigned first. All
master operations need ns table to be assigned, etc.
For at least two types of data, (1) procedure v2 states, (2) RS groups in
HBASE-6721 we cannot depend on meta being assigned since assignment itself
will depend on accessing this data. The solution in (1) is to implement a
custom WAL format, and custom recover lease and WAL recovery. The solution in
(2) is to have the table to store this data, but also cache it in zk for
bootrapping initial assignments.
For solving both of the above (and possible future use cases if any), I
propose we add a boostrap table concept, which is:
- A set of predefined tables hosted in a separate dir in HDFS.
- A table is only 1 region, not splittable
- Not assigned through regular assignment
- Hosted only on 1 server (typically master)
- Has a dedicated WAL.
- A service does WAL recovery + fencing for these tables.
This has the benefit of using a region to keep the data, but frees us to
re-implement caching and we can use the same WAL / Memstore / Recovery
mechanisms that are battle-tested.

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

[jira] [Commented] (HBASE-13490) Linux Command execution is failing while starting HBase processes using hbase-daemon.sh file


[ 
https://issues.apache.org/jira/browse/HBASE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499512#comment-14499512
 ] 

Hadoop QA commented on HBASE-13490:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726085/HBASE-13490.patch
  against master branch at commit 7fb6055ed7304b05a383a730b64e55e41772bcf8.
  ATTACHMENT ID: 12726085

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+0 tests included{color}.  The patch appears to be a 
documentation, build,
or dev-support patch that doesn't require tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

 {color:red}-1 core zombie tests{color}.  There are 1 zombie test(s):   
at 
org.apache.camel.test.junit4.CamelTestSupport.assertMockEndpointsSatisfied(CamelTestSupport.java:675)
at 
org.apache.camel.component.quartz2.QuartzCronRouteTest.testQuartzCronRoute(QuartzCronRouteTest.java:39)

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13732//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13732//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13732//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13732//console

This message is automatically generated.

 Linux Command execution is failing while starting HBase processes using 
 hbase-daemon.sh file
 

 Key: HBASE-13490
 URL: https://issues.apache.org/jira/browse/HBASE-13490
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 1.0.0
Reporter: Y. SREENIVASULU REDDY
Assignee: Y. SREENIVASULU REDDY
Priority: Minor
 Fix For: 2.0.0

 Attachments: HBASE-13490.patch


 While starting any HBase process (HMaster or Regionserver)
 ulimit command execution is failing.
 {code}
  echo `date` Starting $command on `hostname`  ${HBASE_LOGLOG}
 `ulimit -a`  $HBASE_LOGLOG 21
 {code}
 Log message is follows.
 {noformat}
 Thu Apr 16 19:24:25 IST 2015 Starting regionserver on HOST-10
 /opt/hdfsdata/HA/install/hbase/regionserver/bin/hbase-daemon.sh: line 207: 
 core: command not found
 {noformat}



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

[jira] [Commented] (HBASE-13260) Bootstrap Tables for fun and profit

[
https://issues.apache.org/jira/browse/HBASE-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499457#comment-14499457
]

Enis Soztutar commented on HBASE-13260:
---

Here is a more complete patch for consideration:
https://reviews.apache.org/r/33293/. It does some refactoring, and undos the
WAL proc store in favor of the region-based one (the reason being we may not
want an alternative WAL format).

I think for DDL ops for master, what store is used for performance is
irrelevant. For assignment, the store might become the bottleneck, but in case
of fast procs, there will not be flushes for most of the time (since procs will
get deleted from memstore). So WAL is the bottleneck. Between the WAL format in
WALProcStore and the FSHLog, I did not check which one has more overhead vs
write speed. But both will have to go thru wal IO.

Bootstrap Tables for fun and profit

Key: HBASE-13260
URL: https://issues.apache.org/jira/browse/HBASE-13260
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 2.0.0, 1.1.0

Attachments: hbase-13260_prototype.patch

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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499579#comment-14499579
 ] 

Hadoop QA commented on HBASE-13491:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726095/HBASE-13491.patch
  against master branch at commit 7fb6055ed7304b05a383a730b64e55e41772bcf8.
  ATTACHMENT ID: 12726095

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13733//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13733//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13733//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13733//console

This message is automatically generated.

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices

2015-04-17 Thread Dave Latham (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499782#comment-14499782
 ] 

Dave Latham commented on HBASE-13492:
-

Is this a duplicate of HBASE-13262 ?

 The estimation of result size may be different between ClientScanner and 
 RSRpcServices
 --

 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: ChiaPing Tsai

 The ClientScanner try to find next scanner if remainingResultSize and 
 countdown are bigger than zero. 
 The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
 {code:title=Bar.java|borderStyle=solid}
 @Override
 public Result next() throws IOException {
 
 do {
   ...
   if (values != null  values.length  0) {
 for (Result rs : values) {
   cache.add(rs);
   // We don't make Iterator here
   for (Cell cell : rs.rawCells()) {
 remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
   }
   countdown--;
   this.lastResult = rs;
 }
   }
}while (remainingResultSize  0  countdown  0 
 possiblyNextScanner(countdown, values == null));
 }
 {code}
 RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
 result size
 {code:title=Bar.java|borderStyle=solid}
   @Override
   public ScanResponse scan(final RpcController controller, final ScanRequest 
 request)
   throws ServiceException {
   ...
 if (!results.isEmpty()) {
   for (Result r : results) {
 for (Cell cell : r.rawCells()) {
   currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
   totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
 }
   }
 }
   ...
  }
 {code}
 If we encode the data block, like FastDiff, the cell read from HFile is 
 implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 
 So the RSRpcServices return the results to client with insufficient caching 
 due to result size reaches the limit. ClientScanner consider that current 
 region has no more data, and remainingResultSize and countdown are both 
 bigger than zero. In fact, the remainingResultSize should be smaller than 
 zero, and current region still have more data for reading.
 Does result size calculated by RSRpcServices should be return to client for 
 checking the remainingResultSize ?



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

[jira] [Created] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices

ChiaPing Tsai created HBASE-13492:
-

 Summary: The estimation of result size may be different between 
ClientScanner and RSRpcServices
 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Reporter: ChiaPing Tsai


The ClientScanner try to find next scanner if remainingResultSize and countdown 
are bigger than zero. 
The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
{code:title=Bar.java|borderStyle=solid}
@Override
public Result next() throws IOException {

do {
  ...
  if (values != null  values.length  0) {
for (Result rs : values) {
  cache.add(rs);
  // We don't make Iterator here
  for (Cell cell : rs.rawCells()) {
remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
  }
  countdown--;
  this.lastResult = rs;
}
  }
   }while (remainingResultSize  0  countdown  0 
possiblyNextScanner(countdown, values == null));
}
{code}
RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
result size
{code:title=Bar.java|borderStyle=solid}
  @Override
  public ScanResponse scan(final RpcController controller, final ScanRequest 
request)
  throws ServiceException {
  ...
if (!results.isEmpty()) {
  for (Result r : results) {
for (Cell cell : r.rawCells()) {
  currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
  totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
}
  }
}
  ...
 }
{code}

If we encode the data block, like FastDiff, the cell read from HFile is 
implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 

So the RSRpcServices return the results to client with insufficient caching due 
to result size reaches the limit. ClientScanner consider that current region 
has no more data, and remainingResultSize and countdown are both bigger than 
zero. In fact, the remainingResultSize should be smaller than zero, and current 
region still have more data for reading.

Does result size calculated by RSRpcServices should be return to client for 
checking the remainingResultSize ?





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

[jira] [Commented] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices


[ 
https://issues.apache.org/jira/browse/HBASE-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499665#comment-14499665
 ] 

ChiaPing Tsai commented on HBASE-13492:
---

I scan the data from HFile and Table for estimating heap size of cell by using 
CellUtil.estimatedHeapSizeOf(cell).
The result is as follows:

187 bytes by using HFileScanner to scan HFile 
128 bytes by using ClientScanner to scan Table
(rowLength = 13, familytLength = 1, qualifierLaength = 21, valueLangth = 8, 
tagLength = 0)

So the more cells in single row (wide table), the smaller result size and the 
larger caching are more likely to introduce this trouble

 The estimation of result size may be different between ClientScanner and 
 RSRpcServices
 --

 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Reporter: ChiaPing Tsai

 The ClientScanner try to find next scanner if remainingResultSize and 
 countdown are bigger than zero. 
 The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
 {code:title=Bar.java|borderStyle=solid}
 @Override
 public Result next() throws IOException {
 
 do {
   ...
   if (values != null  values.length  0) {
 for (Result rs : values) {
   cache.add(rs);
   // We don't make Iterator here
   for (Cell cell : rs.rawCells()) {
 remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
   }
   countdown--;
   this.lastResult = rs;
 }
   }
}while (remainingResultSize  0  countdown  0 
 possiblyNextScanner(countdown, values == null));
 }
 {code}
 RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
 result size
 {code:title=Bar.java|borderStyle=solid}
   @Override
   public ScanResponse scan(final RpcController controller, final ScanRequest 
 request)
   throws ServiceException {
   ...
 if (!results.isEmpty()) {
   for (Result r : results) {
 for (Cell cell : r.rawCells()) {
   currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
   totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
 }
   }
 }
   ...
  }
 {code}
 If we encode the data block, like FastDiff, the cell read from HFile is 
 implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 
 So the RSRpcServices return the results to client with insufficient caching 
 due to result size reaches the limit. ClientScanner consider that current 
 region has no more data, and remainingResultSize and countdown are both 
 bigger than zero. In fact, the remainingResultSize should be smaller than 
 zero, and current region still have more data for reading.
 Does result size calculated by RSRpcServices should be return to client for 
 checking the remainingResultSize ?



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

[jira] [Commented] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices


[ 
https://issues.apache.org/jira/browse/HBASE-13492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499931#comment-14499931
 ] 

ChiaPing Tsai commented on HBASE-13492:
---

hi [~davelatham] 
Yes indeed, it certainly is. Thanks for reminding me.


 The estimation of result size may be different between ClientScanner and 
 RSRpcServices
 --

 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: ChiaPing Tsai

 The ClientScanner try to find next scanner if remainingResultSize and 
 countdown are bigger than zero. 
 The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
 {code:title=Bar.java|borderStyle=solid}
 @Override
 public Result next() throws IOException {
 
 do {
   ...
   if (values != null  values.length  0) {
 for (Result rs : values) {
   cache.add(rs);
   // We don't make Iterator here
   for (Cell cell : rs.rawCells()) {
 remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
   }
   countdown--;
   this.lastResult = rs;
 }
   }
}while (remainingResultSize  0  countdown  0 
 possiblyNextScanner(countdown, values == null));
 }
 {code}
 RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
 result size
 {code:title=Bar.java|borderStyle=solid}
   @Override
   public ScanResponse scan(final RpcController controller, final ScanRequest 
 request)
   throws ServiceException {
   ...
 if (!results.isEmpty()) {
   for (Result r : results) {
 for (Cell cell : r.rawCells()) {
   currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
   totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
 }
   }
 }
   ...
  }
 {code}
 If we encode the data block, like FastDiff, the cell read from HFile is 
 implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 
 So the RSRpcServices return the results to client with insufficient caching 
 due to result size reaches the limit. ClientScanner consider that current 
 region has no more data, and remainingResultSize and countdown are both 
 bigger than zero. In fact, the remainingResultSize should be smaller than 
 zero, and current region still have more data for reading.
 Does result size calculated by RSRpcServices should be return to client for 
 checking the remainingResultSize ?



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

[jira] [Updated] (HBASE-13486) region_status.rb broken with NameError: uninitialized constant IOException

2015-04-17 Thread Ted Yu (JIRA)


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

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

Thanks for the patch, Samir.

 region_status.rb broken with NameError: uninitialized constant IOException
 --

 Key: HBASE-13486
 URL: https://issues.apache.org/jira/browse/HBASE-13486
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 2.0.0
Reporter: Samir Ahmic
Assignee: Samir Ahmic
 Fix For: 2.0.0

 Attachments: HBASE-13486.patch


 {code}
  $ hbase org.jruby.Main region_status.rb
 2015-04-16 10:59:25,972 WARN  [main] util.NativeCodeLoader: Unable to load 
 native-hadoop library for your platform... using builtin-java classes where 
 applicable
 NameError: uninitialized constant IOException
   const_missing at org/jruby/RubyModule.java:2647
  (root) at region_status.rb:106
 {code}



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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule

2015-04-17 Thread Ted Yu (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14499834#comment-14499834
 ] 

Ted Yu commented on HBASE-13491:


+1

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices


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

ChiaPing Tsai updated HBASE-13492:
--
Affects Version/s: 1.0.0

 The estimation of result size may be different between ClientScanner and 
 RSRpcServices
 --

 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: ChiaPing Tsai

 The ClientScanner try to find next scanner if remainingResultSize and 
 countdown are bigger than zero. 
 The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
 {code:title=Bar.java|borderStyle=solid}
 @Override
 public Result next() throws IOException {
 
 do {
   ...
   if (values != null  values.length  0) {
 for (Result rs : values) {
   cache.add(rs);
   // We don't make Iterator here
   for (Cell cell : rs.rawCells()) {
 remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
   }
   countdown--;
   this.lastResult = rs;
 }
   }
}while (remainingResultSize  0  countdown  0 
 possiblyNextScanner(countdown, values == null));
 }
 {code}
 RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
 result size
 {code:title=Bar.java|borderStyle=solid}
   @Override
   public ScanResponse scan(final RpcController controller, final ScanRequest 
 request)
   throws ServiceException {
   ...
 if (!results.isEmpty()) {
   for (Result r : results) {
 for (Cell cell : r.rawCells()) {
   currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
   totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
 }
   }
 }
   ...
  }
 {code}
 If we encode the data block, like FastDiff, the cell read from HFile is 
 implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 
 So the RSRpcServices return the results to client with insufficient caching 
 due to result size reaches the limit. ClientScanner consider that current 
 region has no more data, and remainingResultSize and countdown are both 
 bigger than zero. In fact, the remainingResultSize should be smaller than 
 zero, and current region still have more data for reading.
 Does result size calculated by RSRpcServices should be return to client for 
 checking the remainingResultSize ?



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

[jira] [Resolved] (HBASE-13492) The estimation of result size may be different between ClientScanner and RSRpcServices


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

ChiaPing Tsai resolved HBASE-13492.
---
Resolution: Duplicate

 The estimation of result size may be different between ClientScanner and 
 RSRpcServices
 --

 Key: HBASE-13492
 URL: https://issues.apache.org/jira/browse/HBASE-13492
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: ChiaPing Tsai

 The ClientScanner try to find next scanner if remainingResultSize and 
 countdown are bigger than zero. 
 The remainingResultSize is calculated by CellUtil.estimatedHeapSizeOf(cell)
 {code:title=Bar.java|borderStyle=solid}
 @Override
 public Result next() throws IOException {
 
 do {
   ...
   if (values != null  values.length  0) {
 for (Result rs : values) {
   cache.add(rs);
   // We don't make Iterator here
   for (Cell cell : rs.rawCells()) {
 remainingResultSize -= CellUtil.estimatedHeapSizeOf(cell);
   }
   countdown--;
   this.lastResult = rs;
 }
   }
}while (remainingResultSize  0  countdown  0 
 possiblyNextScanner(countdown, values == null));
 }
 {code}
 RSRpcServices also use CellUtil.estimatedHeapSizeOf(cell) to calculate the 
 result size
 {code:title=Bar.java|borderStyle=solid}
   @Override
   public ScanResponse scan(final RpcController controller, final ScanRequest 
 request)
   throws ServiceException {
   ...
 if (!results.isEmpty()) {
   for (Result r : results) {
 for (Cell cell : r.rawCells()) {
   currentScanResultSize += CellUtil.estimatedHeapSizeOf(cell);
   totalCellSize += CellUtil.estimatedSerializedSizeOf(cell);
 }
   }
 }
   ...
  }
 {code}
 If we encode the data block, like FastDiff, the cell read from HFile is 
 implemented by ClonedSeekerState. And it's heap size is bigger than KeyValue. 
 So the RSRpcServices return the results to client with insufficient caching 
 due to result size reaches the limit. ClientScanner consider that current 
 region has no more data, and remainingResultSize and countdown are both 
 bigger than zero. In fact, the remainingResultSize should be smaller than 
 zero, and current region still have more data for reading.
 Does result size calculated by RSRpcServices should be return to client for 
 checking the remainingResultSize ?



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

[jira] [Created] (HBASE-13493) ISE/HTTP 500 when opening table details from standby master.

2015-04-17 Thread Serhiy Bilousov (JIRA)

Serhiy Bilousov created HBASE-13493:
---

 Summary: ISE/HTTP 500 when opening table details from standby 
master.
 Key: HBASE-13493
 URL: https://issues.apache.org/jira/browse/HBASE-13493
 Project: HBase
  Issue Type: Bug
  Components: UI
Affects Versions: 0.98.9
Reporter: Serhiy Bilousov
Priority: Minor


Given: There are 3 HBase Masters on-line (1 online and 2 stand by)
When: Navigate to the 
http://hbase_snandby_master_url:60010/table.jsp?name=TABLE_NAME
Then: HTTP ERROR 500 - INTERNAL_SERVER_ERROR thrown.


{noformat}
HTTP ERROR 500

Problem accessing /table.jsp. Reason:

INTERNAL_SERVER_ERROR
Caused by:

java.lang.NullPointerException
at 
org.apache.hadoop.hbase.generated.master.table_jsp._jspService(table_jsp.java:71)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
at 
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1221)
at 
org.apache.hadoop.http.lib.StaticUserWebFilter$StaticUserFilter.doFilter(StaticUserWebFilter.java:109)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at 
org.apache.hadoop.http.HttpServer$QuotingInputFilter.doFilter(HttpServer.java:1081)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at org.apache.hadoop.http.NoCacheFilter.doFilter(NoCacheFilter.java:45)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
at 
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at 
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
{noformat}



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

[jira] [Updated] (HBASE-13307) Making methods under ScannerV2#next inlineable, faster


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

stack updated HBASE-13307:
--
  Resolution: Fixed
Release Note: Made methods smaller under Scanner#next so inlinable and 
compilable (was getting 'too big to compile' from hotspot). Use of unsafe to 
parse shorts rather than use BB#getShort... faster, etc.
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Pushed to master branch too.

Thanks for reviews AR.

 Making methods under ScannerV2#next inlineable, faster
 --

 Key: HBASE-13307
 URL: https://issues.apache.org/jira/browse/HBASE-13307
 Project: HBase
  Issue Type: Sub-task
  Components: Scanners
Reporter: stack
Assignee: stack
 Fix For: 2.0.0, 1.1.0

 Attachments: 13307.txt, 13307v2.branch-1.txt, 13307v3.branch-1.txt, 
 13307v4.branch-1.txt, 13307v5.branch-1.txt, 13307v6.branch-1.txt, 
 13307v6.txt, 13307v7.txt, cpu.png, gc.png, next.png, traces.8.svg, 
 traces.9.svg


 See parent issue for patch and evidence.
 I was looking at graphs of our scan and found that methods were 'too big' to 
 be inlined (looking at jvm compilation and inlining output flags -- see 
 parent for list).  Changing method size helped some. Let me commit the 
 resultant patch.



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500209#comment-14500209
 ] 

Mikhail Antonov commented on HBASE-13351:
-

I've included it in the patch for superusers QoS already :) but since that 
wasn't committed yet, this change doesn't help tests in this jira.

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners

2015-04-17 Thread Jonathan Lawlor (JIRA)

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

Jonathan Lawlor updated HBASE-13090:

Release Note:
Previously, there was no way to enforce a time limit on scan RPC requests. The
server would receive a scan RPC request and take as much time as it needed to
accumulate enough results to reach a limit or exhaust the region. The problem
with this approach was that, in the case of a very selective scan, the
processing of the scan could take too long and cause timeouts client side.

With this fix, the server will now enforce a time limit on the execution of
scan RPC requests. When a scan RPC request arrives to the server, a time limit
is calculated to be half of whichever timeout value is more restictive between
the configurations (hbase.client.scanner.timeout.period and
hbase.rpc.timeout). When the time limit is reached, the server will return
whatever results it has accumulated up to that point. The results may be empty.

To ensure that timeout checks do not occur too often (which would hurt the
performance of scans), the configuration
hbase.cells.scanned.per.heartbeat.check has been introduced. This
configuration controls how often System.currentTimeMillis() is called to update
the progress towards the time limit. Currently, the default value of this
configuration value is 1. Specifying a smaller value will provide a tighter
bound on the time limit, but may hurt scan performance due to the higher
frequency of calls to System.currentTimeMillis().

Protobuf models for ScanRequest and ScanResponse have been updated so that
heartbeat support can be communicated. Support for heartbeat messages is
specified in the request sent to the server via
ScanRequest.Builder#setClientHandlesHeartbeats. Only when the server sees that
ScanRequest#getClientHandlesHeartbeats() is true will it send heartbeat
messages back to the client. A response is marked as a heartbeat message via
the boolean flag ScanResponse#getHeartbeatMessage

Progress heartbeats for long running scanners
-

Key: HBASE-13090
URL: https://issues.apache.org/jira/browse/HBASE-13090
Project: HBase
Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.2.0

Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch,
HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch,
HBASE-13090-v6.patch, HBASE-13090-v7.patch

It can be necessary to set very long timeouts for clients that issue scans
over large regions when all data in the region might be filtered out
depending on scan criteria. This is a usability concern because it can be
hard to identify what worst case timeout to use until scans are
occasionally/intermittently failing in production, depending on variable scan
criteria. It would be better if the client-server scan protocol can send back
periodic progress heartbeats to clients as long as server scanners are alive
and making progress.
This is related but orthogonal to streaming scan (HBASE-13071).

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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority

2015-04-17 Thread Josh Elser (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500275#comment-14500275
 ] 

Josh Elser commented on HBASE-13351:


Ahh, forgot about that. FTR, it looks like 20 isn't enough for some of these 
still failing tests. Bumped up to 40 makes them pass. The short-circuit 
connection fix should help keep an upper bound there, so I'm not too worried 
about it ATM.

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Updated] (HBASE-13456) Improve HFilePrettyPrinter first hbase:meta region processing

2015-04-17 Thread Jerry He (JIRA)


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

Jerry He updated HBASE-13456:
-
   Resolution: Fixed
Fix Version/s: 1.1.0
   2.0.0
   Status: Resolved  (was: Patch Available)

Pushed to master, branch-1, branch-1.1.  Thanks for the patch.

 Improve HFilePrettyPrinter first hbase:meta region processing 
 --

 Key: HBASE-13456
 URL: https://issues.apache.org/jira/browse/HBASE-13456
 Project: HBase
  Issue Type: Improvement
  Components: util
Affects Versions: 2.0.0, 0.98.12
 Environment: x86_64 GNU/Linux
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13456-0.98-v2.patch, HBASE-13456-0.98.patch, 
 HBASE-13456-master-v2.patch, HBASE-13456-master.patch


 HFilePrettyPrinter have couple of small issues when -r option is used with 
 hbase:meta region as argument:
 1. Processing files in oldWals and recovered.edits directories
 {code}
 $ hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1
 Number of region files found - 3
 Found file[1] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Found file[2] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Found file[3] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 2015-04-13 14:08:21,461 ERROR [main] hfile.HFilePrettyPrinter: Error reading 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile 
 Trailer from file 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 {code}
 2. If full region name is passed as argument we have wrong encoded region 
 name returned:
 {code}
 hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1.1588230740
 region dir - hdfs://P3cluster/hbase/data/hbase/meta/104563571
 2015-04-13 14:21:43,012 INFO  [main] Configuration.deprecation: 
 hadoop.native.lib is deprecated. Instead, use io.native.lib.available
 2015-04-13 14:21:43,711 INFO  [main] util.ChecksumType: Checksum using 
 org.apache.hadoop.util.PureJavaCrc32
 2015-04-13 14:21:43,717 INFO  [main] util.ChecksumType: Checksum can use 
 org.apache.hadoop.util.PureJavaCrc32C
 2015-04-13 14:21:43,899 ERROR [main] hfile.HFilePrettyPrinter: Error parsing 
 command-line options
 java.io.FileNotFoundException: File 
 hdfs://P3cluster/hbase/data/hbase/meta/104563571 does not exist.
 {code}
 I have modified HFilePrettyPrinter.java to address this issues. Patch is 
 coming soon.



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

[jira] [Updated] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority

2015-04-17 Thread Josh Elser (JIRA)


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

Josh Elser updated HBASE-13351:
---
Attachment: HBASE-13351-v5.patch

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351-v5.patch, 
 HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500292#comment-14500292
 ] 

Nick Dimiduk commented on HBASE-13491:
--

+1 for branch-1.1

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13260) Bootstrap Tables for fun and profit

[
https://issues.apache.org/jira/browse/HBASE-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500363#comment-14500363
]

Enis Soztutar commented on HBASE-13260:
---

bq. not be flushes for most of the time (since procs will get deleted from
memstore).
Devaraj, offline, pointed out that this is not true, duh! The deletes of
procedures is still a tombstone which increases the memstore size.
bq. aside compactions, I don't think the perf problem me and stack raised is
around adding procs to the WAL, but it is on replay
Valid point. We have the regular region mechanics at play here. We can also
throw away WALs, once the data is flushed, the flush seqId will be the way to
skip replaying entries from WAL. I think if we enable periodic flushes, it
might help with more regular flushes to get rid of WAL files. We can put
another filter to the replay process to the same affect if needed. Let me spend
some time in testing with millions of procs.

Bootstrap Tables for fun and profit

Key: HBASE-13260
URL: https://issues.apache.org/jira/browse/HBASE-13260
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 2.0.0, 1.1.0

Attachments: hbase-13260_prototype.patch

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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations

2015-04-17 Thread Jerry He (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500421#comment-14500421
 ] 

Jerry He commented on HBASE-13481:
--

That should fix it.
Originally master would also take the value of hbase.regionserver.hostname.
Thanks.

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-13375) Provide HBase superuser higher priority over other users in the RPC handling

2015-04-17 Thread Devaraj Das (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500225#comment-14500225
 ] 

Devaraj Das commented on HBASE-13375:
-

+1

 Provide HBase superuser higher priority over other users in the RPC handling
 

 Key: HBASE-13375
 URL: https://issues.apache.org/jira/browse/HBASE-13375
 Project: HBase
  Issue Type: Improvement
  Components: rpc
Reporter: Devaraj Das
Assignee: Mikhail Antonov
 Fix For: 1.1.0

 Attachments: HBASE-13375-v0.patch, HBASE-13375-v1.patch, 
 HBASE-13375-v1.patch, HBASE-13375-v1.patch, HBASE-13375-v2.patch


 HBASE-13351 annotates Master RPCs so that RegionServer RPCs are treated with 
 a higher priority compared to user RPCs (and they are handled by a separate 
 set of handlers, etc.). It may be good to stretch this to users too - hbase 
 superuser (configured via hbase.superuser) gets higher priority over other 
 users in the RPC handling. That way the superuser can always perform 
 administrative operations on the cluster even if all the normal priority 
 handlers are occupied (for example, we had a situation where all the master's 
 handlers were tied up with many simultaneous createTable RPC calls from 
 multiple users and the master wasn't able to perform any operations initiated 
 by the admin). (Discussed this some with [~enis] and [~elserj]).
 Does this make sense to others?



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

[jira] [Commented] (HBASE-13090) Progress heartbeats for long running scanners

2015-04-17 Thread Jonathan Lawlor (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500349#comment-14500349
 ] 

Jonathan Lawlor commented on HBASE-13090:
-

[~ndimiduk] I believe the change is solid. Just figured with branch-1.1 release 
so close may be a bit 'risky' to stick such a large change in right before 
release. While the unit tests added do stress the relevant code paths, it would 
be nice to run it against a workload that was having timeout problems before to 
prove its worth

 Progress heartbeats for long running scanners
 -

 Key: HBASE-13090
 URL: https://issues.apache.org/jira/browse/HBASE-13090
 Project: HBase
  Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
 Fix For: 2.0.0, 1.2.0

 Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, 
 HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch, 
 HBASE-13090-v6.patch, HBASE-13090-v7.patch


 It can be necessary to set very long timeouts for clients that issue scans 
 over large regions when all data in the region might be filtered out 
 depending on scan criteria. This is a usability concern because it can be 
 hard to identify what worst case timeout to use until scans are 
 occasionally/intermittently failing in production, depending on variable scan 
 criteria. It would be better if the client-server scan protocol can send back 
 periodic progress heartbeats to clients as long as server scanners are alive 
 and making progress.
 This is related but orthogonal to streaming scan (HBASE-13071). 



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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500400#comment-14500400
 ] 

Enis Soztutar commented on HBASE-13481:
---

bq. those overrides intentional?
yes. Coming from eclipse auto-correction. 
bq.I'm not sure if getHostname(Configuration conf, String masterOrRS) is the 
right way to do it. perhaps change to boolean isMaster or something like that.
done
bq. More info on my last comment. It seems that the useThisHostnameInstead 
logic in HRegionServer will break if it is a master.
Good point. I have added hbase.master.hostname parameter for HBASE-12954. Why 
do you think it will break? hostname should not be affected of the bind 
configurations. 

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-12349) Add Maven build support module for a custom version of error-prone

2015-04-17 Thread Ding Yuan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-12349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500285#comment-14500285
 ] 

Ding Yuan commented on HBASE-12349:
---

Ping. Just checking if the custom error-prone has been integrated? Or if there 
is anything that I can further help?

 Add Maven build support module for a custom version of error-prone
 --

 Key: HBASE-12349
 URL: https://issues.apache.org/jira/browse/HBASE-12349
 Project: HBase
  Issue Type: Sub-task
Reporter: Andrew Purtell
 Fix For: 2.0.0


 Add a new Maven build support module that builds and publishes a custom 
 error-prone artifact for use by the rest of the build.



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

[jira] [Updated] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


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

Nick Dimiduk updated HBASE-13491:
-
Attachment: HBASE-13491-branch-1.1.patch

Trying out the pre-commit job for branch-1.1.

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491-branch-1.1.patch, HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500336#comment-14500336
 ] 

Hadoop QA commented on HBASE-13491:
---

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12726205/HBASE-13491-branch-1.1.patch
  against branch-1.1 branch at commit 0dfeba3d7854c66b80dfc4e0d465d63dce617bb9.
  ATTACHMENT ID: 12726205

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13735//console

This message is automatically generated.

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491-branch-1.1.patch, HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Updated] (HBASE-13481) Master should respect master (old) DNS/bind related configurations


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

Enis Soztutar updated HBASE-13481:
--
Attachment: hbase-13481_v2.patch

Updated patch addressing reviews. 

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Updated] (HBASE-13487) Doc KEEP_DELETED_CELLS


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

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

Thanks for the reviews [~anoop.hbase] and [~ashish singhi] Pushed to master.

 Doc KEEP_DELETED_CELLS
 --

 Key: HBASE-13487
 URL: https://issues.apache.org/jira/browse/HBASE-13487
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: stack
Assignee: stack
 Fix For: 2.0.0

 Attachments: 13487.txt


 Let me doc this nice feature that has been around a long time but is not 
 explained other than in Lars lectures. I was talking to someone and could not 
 explain this feature myself until Lars set me straight.



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500160#comment-14500160
 ] 

Mikhail Antonov commented on HBASE-13351:
-

TestRollingRestart seems to have failed 
(https://builds.apache.org/job/PreCommit-HBASE-Build/13729//testReport/TEST-org.apache.hadoop.hbase.master.TestRollingRestart/xml/_init_/),
 though it does look spurious to me..Want to retry?

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500178#comment-14500178
 ] 

Anoop Sam John commented on HBASE-13491:


Ping [~enis], [~ndimiduk]. Bug fix applicable for 1.0 and 1.1 branches. Can I 
get your +1s?

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13090) Progress heartbeats for long running scanners

[
https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500331#comment-14500331
]

Nick Dimiduk commented on HBASE-13090:
--

bq. I wanted to put this in hbase 1.1 because it so sweet but
[~jonathan.lawlor] won't let me... says too much change too close to
release it might be a bit 'risky'. Ahem.

That's a shame; this seems very important for Phoenix users who are pushing the
line on OLAP-kinds of queries. What can we do to raise your confidence in the
patch for branch-1.1? IT tests? CM?

Progress heartbeats for long running scanners
-

Key: HBASE-13090
URL: https://issues.apache.org/jira/browse/HBASE-13090
Project: HBase
Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.2.0

Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch,
HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch,
HBASE-13090-v6.patch, HBASE-13090-v7.patch

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

[jira] [Commented] (HBASE-13491) Issue in FuzzyRowFilter#getNextForFuzzyRule


[ 
https://issues.apache.org/jira/browse/HBASE-13491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500345#comment-14500345
 ] 

Nick Dimiduk commented on HBASE-13491:
--

I checked the console output: branch-1.1 precommit appears to be working 
correctly and indeed this patch does not apply cleanly.

 Issue in FuzzyRowFilter#getNextForFuzzyRule
 ---

 Key: HBASE-13491
 URL: https://issues.apache.org/jira/browse/HBASE-13491
 Project: HBase
  Issue Type: Bug
  Components: Filters
Affects Versions: 1.0.0
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Fix For: 2.0.0, 1.0.1, 1.1.0, 1.2.0

 Attachments: HBASE-13491-branch-1.1.patch, HBASE-13491.patch


 {code}
 for (int i = 0; i  result.length; i++) {
   if (i = fuzzyKeyMeta.length || fuzzyKeyMeta[i] == 1) {
 result[i] = row[offset + i];
 if (!order.isMax(row[i])) {
   // this is non-fixed position and is not at max value, hence we 
 can increase it
   toInc = i;
 }
   }
 {code}
 See we take row bytes with out considering the row offset.  The test cases 
 are passing as we pass 0 offset row bytes. Change in the test will reveal the 
 bug.
 Came across this when I was working on HBASE-11425



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

[jira] [Commented] (HBASE-13375) Provide HBase superuser higher priority over other users in the RPC handling


[ 
https://issues.apache.org/jira/browse/HBASE-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500154#comment-14500154
 ] 

Mikhail Antonov commented on HBASE-13375:
-

[~devaraj], [~srikanth235] any comments, feedbacks on latest patch?

 Provide HBase superuser higher priority over other users in the RPC handling
 

 Key: HBASE-13375
 URL: https://issues.apache.org/jira/browse/HBASE-13375
 Project: HBase
  Issue Type: Improvement
  Components: rpc
Reporter: Devaraj Das
Assignee: Mikhail Antonov
 Fix For: 1.1.0

 Attachments: HBASE-13375-v0.patch, HBASE-13375-v1.patch, 
 HBASE-13375-v1.patch, HBASE-13375-v1.patch, HBASE-13375-v2.patch


 HBASE-13351 annotates Master RPCs so that RegionServer RPCs are treated with 
 a higher priority compared to user RPCs (and they are handled by a separate 
 set of handlers, etc.). It may be good to stretch this to users too - hbase 
 superuser (configured via hbase.superuser) gets higher priority over other 
 users in the RPC handling. That way the superuser can always perform 
 administrative operations on the cluster even if all the normal priority 
 handlers are occupied (for example, we had a situation where all the master's 
 handlers were tied up with many simultaneous createTable RPC calls from 
 multiple users and the master wasn't able to perform any operations initiated 
 by the admin). (Discussed this some with [~enis] and [~elserj]).
 Does this make sense to others?



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

[jira] [Commented] (HBASE-13090) Progress heartbeats for long running scanners

[
https://issues.apache.org/jira/browse/HBASE-13090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500078#comment-14500078
]

stack commented on HBASE-13090:
---

+1 carried over from rb. This is a beautiful patch. I will commit later today.
The long line is from generated code and is likely cause of the checkstyle
complaint. I'll check it out on commit (and do any fixup if needed).

Progress heartbeats for long running scanners
-

Key: HBASE-13090
URL: https://issues.apache.org/jira/browse/HBASE-13090
Project: HBase
Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch,
HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch,
HBASE-13090-v6.patch, HBASE-13090-v7.patch

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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500170#comment-14500170
 ] 

Mikhail Antonov commented on HBASE-13351:
-

Just wondering if you were going to also change default metahandler count 
(DEFAULT_REGION_SERVER_HIGH_PRIORITY_HANDLER_COUNT prop) to 20 as it seems like 
something worth trying?

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13490) Linux Command execution is failing while starting HBase processes using hbase-daemon.sh file


[ 
https://issues.apache.org/jira/browse/HBASE-13490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500076#comment-14500076
 ] 

Elliott Clark commented on HBASE-13490:
---

You can remove ` and echo to simplify things.

 Linux Command execution is failing while starting HBase processes using 
 hbase-daemon.sh file
 

 Key: HBASE-13490
 URL: https://issues.apache.org/jira/browse/HBASE-13490
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 1.0.0
Reporter: Y. SREENIVASULU REDDY
Assignee: Y. SREENIVASULU REDDY
Priority: Minor
 Fix For: 2.0.0

 Attachments: HBASE-13490.patch


 While starting any HBase process (HMaster or Regionserver)
 ulimit command execution is failing.
 {code}
  echo `date` Starting $command on `hostname`  ${HBASE_LOGLOG}
 `ulimit -a`  $HBASE_LOGLOG 21
 {code}
 Log message is follows.
 {noformat}
 Thu Apr 16 19:24:25 IST 2015 Starting regionserver on HOST-10
 /opt/hdfsdata/HA/install/hbase/regionserver/bin/hbase-daemon.sh: line 207: 
 core: command not found
 {noformat}



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

[jira] [Commented] (HBASE-13375) Provide HBase superuser higher priority over other users in the RPC handling


[ 
https://issues.apache.org/jira/browse/HBASE-13375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500156#comment-14500156
 ] 

Mikhail Antonov commented on HBASE-13375:
-

Thanks for review!

 Provide HBase superuser higher priority over other users in the RPC handling
 

 Key: HBASE-13375
 URL: https://issues.apache.org/jira/browse/HBASE-13375
 Project: HBase
  Issue Type: Improvement
  Components: rpc
Reporter: Devaraj Das
Assignee: Mikhail Antonov
 Fix For: 1.1.0

 Attachments: HBASE-13375-v0.patch, HBASE-13375-v1.patch, 
 HBASE-13375-v1.patch, HBASE-13375-v1.patch, HBASE-13375-v2.patch


 HBASE-13351 annotates Master RPCs so that RegionServer RPCs are treated with 
 a higher priority compared to user RPCs (and they are handled by a separate 
 set of handlers, etc.). It may be good to stretch this to users too - hbase 
 superuser (configured via hbase.superuser) gets higher priority over other 
 users in the RPC handling. That way the superuser can always perform 
 administrative operations on the cluster even if all the normal priority 
 handlers are occupied (for example, we had a situation where all the master's 
 handlers were tied up with many simultaneous createTable RPC calls from 
 multiple users and the master wasn't able to perform any operations initiated 
 by the admin). (Discussed this some with [~enis] and [~elserj]).
 Does this make sense to others?



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

[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners

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

stack updated HBASE-13090:
--
Fix Version/s: 1.2.0
2.0.0

Want to do a release note [~jonathan.lawlor]?

I wanted to put this in hbase 1.1 because it so sweet but [~jonathan.lawlor]
won't let me... says too much change too close to release it might be a bit
'risky'. Ahem.

So, marking 1.2. and 2.0.

Progress heartbeats for long running scanners
-

Key: HBASE-13090
URL: https://issues.apache.org/jira/browse/HBASE-13090
Project: HBase
Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
Fix For: 2.0.0, 1.2.0

Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch,
HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch,
HBASE-13090-v6.patch, HBASE-13090-v7.patch

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

[jira] [Commented] (HBASE-13486) region_status.rb broken with NameError: uninitialized constant IOException


[ 
https://issues.apache.org/jira/browse/HBASE-13486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500147#comment-14500147
 ] 

Hudson commented on HBASE-13486:


FAILURE: Integrated in HBase-TRUNK #6384 (See 
[https://builds.apache.org/job/HBase-TRUNK/6384/])
HBASE-13486 region_status.rb broken with NameError: uninitialized constant 
IOException (Samir Ahmic) (tedyu: rev bcc5e1b35329c64c8df144e87af5a01cbbfad01b)
* bin/region_status.rb


 region_status.rb broken with NameError: uninitialized constant IOException
 --

 Key: HBASE-13486
 URL: https://issues.apache.org/jira/browse/HBASE-13486
 Project: HBase
  Issue Type: Bug
  Components: scripts
Affects Versions: 2.0.0
Reporter: Samir Ahmic
Assignee: Samir Ahmic
 Fix For: 2.0.0

 Attachments: HBASE-13486.patch


 {code}
  $ hbase org.jruby.Main region_status.rb
 2015-04-16 10:59:25,972 WARN  [main] util.NativeCodeLoader: Unable to load 
 native-hadoop library for your platform... using builtin-java classes where 
 applicable
 NameError: uninitialized constant IOException
   const_missing at org/jruby/RubyModule.java:2647
  (root) at region_status.rb:106
 {code}



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority

2015-04-17 Thread Josh Elser (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500207#comment-14500207
 ] 

Josh Elser commented on HBASE-13351:


I think between the two of us, it should happen. I can include it in my next 
patch since I'm already working on it :)

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13487) Doc KEEP_DELETED_CELLS


[ 
https://issues.apache.org/jira/browse/HBASE-13487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500450#comment-14500450
 ] 

Hudson commented on HBASE-13487:


SUCCESS: Integrated in HBase-TRUNK #6385 (See 
[https://builds.apache.org/job/HBase-TRUNK/6385/])
HBASE-13487 Doc KEEP_DELETED_CELLS (stack: rev 
0dfeba3d7854c66b80dfc4e0d465d63dce617bb9)
* src/main/asciidoc/_chapters/schema_design.adoc
* hbase-client/src/main/java/org/apache/hadoop/hbase/HColumnDescriptor.java
* hbase-shell/src/main/ruby/shell/commands/create.rb
* src/main/asciidoc/_chapters/datamodel.adoc


 Doc KEEP_DELETED_CELLS
 --

 Key: HBASE-13487
 URL: https://issues.apache.org/jira/browse/HBASE-13487
 Project: HBase
  Issue Type: Task
  Components: documentation
Reporter: stack
Assignee: stack
 Fix For: 2.0.0

 Attachments: 13487.txt


 Let me doc this nice feature that has been around a long time but is not 
 explained other than in Lars lectures. I was talking to someone and could not 
 explain this feature myself until Lars set me straight.



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

[jira] [Commented] (HBASE-13307) Making methods under ScannerV2#next inlineable, faster


[ 
https://issues.apache.org/jira/browse/HBASE-13307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500449#comment-14500449
 ] 

Hudson commented on HBASE-13307:


SUCCESS: Integrated in HBase-TRUNK #6385 (See 
[https://builds.apache.org/job/HBase-TRUNK/6385/])
HBASE-13307 Making methods under ScannerV2#next inlineable, faster (stack: rev 
92af695ea123c8433dd5970af065e38694c21243)
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RSRpcServices.java
* hbase-common/src/main/java/org/apache/hadoop/hbase/util/Bytes.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HStore.java
* hbase-server/src/test/java/org/apache/hadoop/hbase/regionserver/TestTags.java
* hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
* 
hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFileReaderImpl.java


 Making methods under ScannerV2#next inlineable, faster
 --

 Key: HBASE-13307
 URL: https://issues.apache.org/jira/browse/HBASE-13307
 Project: HBase
  Issue Type: Sub-task
  Components: Scanners
Reporter: stack
Assignee: stack
 Fix For: 2.0.0, 1.1.0

 Attachments: 13307.txt, 13307v2.branch-1.txt, 13307v3.branch-1.txt, 
 13307v4.branch-1.txt, 13307v5.branch-1.txt, 13307v6.branch-1.txt, 
 13307v6.txt, 13307v7.txt, cpu.png, gc.png, next.png, traces.8.svg, 
 traces.9.svg


 See parent issue for patch and evidence.
 I was looking at graphs of our scan and found that methods were 'too big' to 
 be inlined (looking at jvm compilation and inlining output flags -- see 
 parent for list).  Changing method size helped some. Let me commit the 
 resultant patch.



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500606#comment-14500606
 ] 

Hadoop QA commented on HBASE-13351:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726202/HBASE-13351-v5.patch
  against master branch at commit 0dfeba3d7854c66b80dfc4e0d465d63dce617bb9.
  ATTACHMENT ID: 12726202

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 36 new 
or modified tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13734//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13734//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13734//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13734//console

This message is automatically generated.

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351-v5.patch, 
 HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13448) New Cell implementation with cached component offsets/lengths


[ 
https://issues.apache.org/jira/browse/HBASE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500517#comment-14500517
 ] 

stack commented on HBASE-13448:
---

I think this issue is actually a critical part of our moving to Cell.

+ Currently, our KeyValue comparators do a bunch of 'carry-over' of calculated 
lengths -- e.g. key, value, row, family, etc., lengths -- from method to method 
so we don't have to recalc each time (because reparse costs CPU).
+ Moving to the Cell Interface and CellComparator, Cell does not expose means 
for passing 'carry-over's, and besides, carry-overs only boost parse when the 
Cell is serialized as our KeyValue is now (they may help when the serialization 
format is otherwise, but may also be of no use).
+ The CellComparator patch over in HBASE-10800 which replaces all 
KeyValueComparators with CellComparator currently preserves methods that take 
'carry-over', methods that won't make much sense when the serialization is 
other than current KeyValue.
+  We will need to remove all the carry-over methods in CellComparator to undo 
our explicit dependence on KeyValue serialization.

Having the Cell internally do the caching rather than have the caller call the 
appropriate methods with a carry-over will be the way to go going forward. Cell 
knows best what needs caching.

 New Cell implementation with cached component offsets/lengths
 -

 Key: HBASE-13448
 URL: https://issues.apache.org/jira/browse/HBASE-13448
 Project: HBase
  Issue Type: Sub-task
  Components: Scanners
Reporter: Anoop Sam John
Assignee: Anoop Sam John
 Attachments: HBASE-13448.patch, gc.png, hits.png


 This can be extension to KeyValue and can be instantiated and used in read 
 path.



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

[jira] [Commented] (HBASE-13456) Improve HFilePrettyPrinter first hbase:meta region processing


[ 
https://issues.apache.org/jira/browse/HBASE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500667#comment-14500667
 ] 

Hudson commented on HBASE-13456:


FAILURE: Integrated in HBase-1.1 #405 (See 
[https://builds.apache.org/job/HBase-1.1/405/])
HBASE-13456 Improve HFilePrettyPrinter first hbase:meta region processing 
(Samir Ahmic) (jerryjch: rev 3c81d656e02aca80fb9f6fe0636b953202c79054)
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java


 Improve HFilePrettyPrinter first hbase:meta region processing 
 --

 Key: HBASE-13456
 URL: https://issues.apache.org/jira/browse/HBASE-13456
 Project: HBase
  Issue Type: Improvement
  Components: util
Affects Versions: 2.0.0, 0.98.12
 Environment: x86_64 GNU/Linux
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13456-0.98-v2.patch, HBASE-13456-0.98.patch, 
 HBASE-13456-master-v2.patch, HBASE-13456-master.patch


 HFilePrettyPrinter have couple of small issues when -r option is used with 
 hbase:meta region as argument:
 1. Processing files in oldWals and recovered.edits directories
 {code}
 $ hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1
 Number of region files found - 3
 Found file[1] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Found file[2] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Found file[3] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 2015-04-13 14:08:21,461 ERROR [main] hfile.HFilePrettyPrinter: Error reading 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile 
 Trailer from file 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 {code}
 2. If full region name is passed as argument we have wrong encoded region 
 name returned:
 {code}
 hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1.1588230740
 region dir - hdfs://P3cluster/hbase/data/hbase/meta/104563571
 2015-04-13 14:21:43,012 INFO  [main] Configuration.deprecation: 
 hadoop.native.lib is deprecated. Instead, use io.native.lib.available
 2015-04-13 14:21:43,711 INFO  [main] util.ChecksumType: Checksum using 
 org.apache.hadoop.util.PureJavaCrc32
 2015-04-13 14:21:43,717 INFO  [main] util.ChecksumType: Checksum can use 
 org.apache.hadoop.util.PureJavaCrc32C
 2015-04-13 14:21:43,899 ERROR [main] hfile.HFilePrettyPrinter: Error parsing 
 command-line options
 java.io.FileNotFoundException: File 
 hdfs://P3cluster/hbase/data/hbase/meta/104563571 does not exist.
 {code}
 I have modified HFilePrettyPrinter.java to address this issues. Patch is 
 coming soon.



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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations

2015-04-17 Thread Jerry He (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500723#comment-14500723
 ] 

Jerry He commented on HBASE-13481:
--

{quote}
+  public static String getHostname(Configuration conf, boolean isMaster)
+  throws UnknownHostException {
+String hostname = conf.get(HRegionServer.RS_HOSTNAME_KEY);
 if (hostname == null || hostname.isEmpty()) {
{quote}
This first conf.get() should handle isMaster as well?

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-11290) Unlock RegionStates

2015-04-17 Thread Virag Kothari (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500751#comment-14500751
 ] 

Virag Kothari commented on HBASE-11290:
---

Idlock() takes care of releasing locks so its better than the LockCache which 
relies on guava's lazy eviction. 
I had taken a look before and will put up an updated patch on weekend. Sorry 
for delay, its been long time since this jira is open.

 Unlock RegionStates
 ---

 Key: HBASE-11290
 URL: https://issues.apache.org/jira/browse/HBASE-11290
 Project: HBase
  Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Virag Kothari
 Fix For: 2.0.0, 1.1.0, 0.98.13

 Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, 
 HBASE-11290.draft.patch


 Even though RegionStates is a highly accessed data structure in HMaster. Most 
 of it's methods are synchronized. Which limits concurrency. Even simply 
 making some of the getters non-synchronized by using concurrent data 
 structures has helped with region assignments. We can go as simple as this 
 approach or create locks per region or a bucket lock per region bucket.



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

[jira] [Commented] (HBASE-13477) Create metrics on failed requests


[ 
https://issues.apache.org/jira/browse/HBASE-13477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500773#comment-14500773
 ] 

Esteban Gutierrez commented on HBASE-13477:
---

LGTM [~eclark], created HBASE-13495 to track those failures that usually don't 
trigger an exception but can be a symptom of something going on in the clients.

 Create metrics on failed requests
 -

 Key: HBASE-13477
 URL: https://issues.apache.org/jira/browse/HBASE-13477
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13477-v1.patch, HBASE-13477-v2.patch, 
 HBASE-13477-v3.patch, HBASE-13477.patch


 Add a metric on how many requests failed/errored out.



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

[jira] [Updated] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures


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

Esteban Gutierrez updated HBASE-13495:
--
  Assignee: Esteban Gutierrez
Issue Type: Improvement  (was: Bug)

 Create metrics for purged calls, abandoned calls and other RPC failures
 ---

 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez

 Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
 calls are abandoned, purged and other states before the call is executed. 
 This would be helpful to track the rate of channel closed exceptions when 
 100s or 1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Commented] (HBASE-13260) Bootstrap Tables for fun and profit

[
https://issues.apache.org/jira/browse/HBASE-13260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500624#comment-14500624
]

stack commented on HBASE-13260:
---

Skimmed patch. EmbeddedDB freaked me out at first but the more I looked at it,
the more sense it made -- smile (Implementing Admin might be OTT?). How do you
think we will do memstore/WAL/compaction 'tricks' if hosting RS provides
memstore flushing and compaction services [~enis] ?

Bootstrap Tables for fun and profit

Key: HBASE-13260
URL: https://issues.apache.org/jira/browse/HBASE-13260
Project: HBase
Issue Type: Bug
Reporter: Enis Soztutar
Assignee: Enis Soztutar
Fix For: 2.0.0, 1.1.0

Attachments: hbase-13260_prototype.patch

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

[jira] [Commented] (HBASE-1) rest server port should be configurable by hbase-site.xml


[ 
https://issues.apache.org/jira/browse/HBASE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500641#comment-14500641
 ] 

Hudson commented on HBASE-1:


FAILURE: Integrated in Flume-trunk-hbase-1 #97 (See 
[https://builds.apache.org/job/Flume-trunk-hbase-1/97/])
FLUME-2679. Make hbase-1 the default profile (hshreedharan: 
http://git-wip-us.apache.org/repos/asf/flume/repo?p=flume.gita=commith=8443062c8809e3ce4bee864e61d9837c5a243287)
* flume-ng-dist/pom.xml
* flume-ng-sinks/flume-hive-sink/pom.xml
* flume-tools/pom.xml
* flume-ng-sinks/flume-ng-hbase-sink/pom.xml
* pom.xml
* flume-ng-sinks/pom.xml
* flume-ng-sinks/flume-hdfs-sink/pom.xml


 rest server port should be configurable by hbase-site.xml
 -

 Key: HBASE-1
 URL: https://issues.apache.org/jira/browse/HBASE-1
 Project: HBase
  Issue Type: Bug
Reporter: Michael Bieniosek
Priority: Minor
   Original Estimate: 0.25h
  Remaining Estimate: 0.25h

 Currently, to change the port the rest server listens on, I need to pass 
 --port=PORT to the hbase-daemon script.  I'd like to be able to configure 
 this value via the hbase-site.xml file.



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

[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V

2015-04-17 Thread Andrew Purtell (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500654#comment-14500654
 ] 

Andrew Purtell commented on HBASE-10327:


+1 from me. We will need this to be able to compile 0.98 with Java 8. I don't 
believe there are any external users of this. 

 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Created] (HBASE-13494) 0.98: Remove remove(K, V) from type PoolMapK,V

Lars Hofhansl created HBASE-13494:
-

 Summary: 0.98: Remove remove(K, V) from type PoolMapK,V
 Key: HBASE-13494
 URL: https://issues.apache.org/jira/browse/HBASE-13494
 Project: HBase
  Issue Type: Sub-task
Reporter: Lars Hofhansl
 Fix For: 0.98.13


JDK7 will be EOL'ed this month. 0.98 should build with JDK8.
[~apurtell] +1'd this in parent.

Unless I hear objections I'll commit this later today.



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

[jira] [Commented] (HBASE-11290) Unlock RegionStates


[ 
https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500761#comment-14500761
 ] 

Mikhail Antonov commented on HBASE-11290:
-

Thanks [~virag]!

 Unlock RegionStates
 ---

 Key: HBASE-11290
 URL: https://issues.apache.org/jira/browse/HBASE-11290
 Project: HBase
  Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Virag Kothari
 Fix For: 2.0.0, 1.1.0, 0.98.13

 Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch, 
 HBASE-11290.draft.patch


 Even though RegionStates is a highly accessed data structure in HMaster. Most 
 of it's methods are synchronized. Which limits concurrency. Even simply 
 making some of the getters non-synchronized by using concurrent data 
 structures has helped with region assignments. We can go as simple as this 
 approach or create locks per region or a bucket lock per region bucket.



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

[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V

2015-04-17 Thread Andrew Purtell (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500765#comment-14500765
 ] 

Andrew Purtell commented on HBASE-10327:


Yes we wanted to deprecate only originally but then Java 7 rapidly EOLed while 
0.98 is still in active use. I think it's ok to do this given no external users 
but +1 for a release note. 

 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Commented] (HBASE-13467) Prototype using GRPC as IPC mechanism

2015-04-17 Thread Louis Ryan (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500616#comment-14500616
 ] 

Louis Ryan commented on HBASE-13467:


OK as of 
https://github.com/louiscryan/hbase/commit/e2dae9e8e3f648125f1e13e0ff88944935ad39a3
  I have a working client. 

You can run it with lots of cycles just don't make the payloads too large until

https://github.com/netty/netty/issues/3643

is fixed.

 Prototype using GRPC as IPC mechanism
 -

 Key: HBASE-13467
 URL: https://issues.apache.org/jira/browse/HBASE-13467
 Project: HBase
  Issue Type: Improvement
  Components: API
Affects Versions: 2.0.0
Reporter: Louis Ryan
Priority: Minor

 GRPC provide an RPC layer for protocol buffers on top of Netty 4/5. This 
 could be used to replace the current internal implementation.
 GRPC supports some advanced features like streaming, async, flow-control, 
 cancellation  timeout which might be useful
 Will prototype on GitHub here if folks are interested 
 https://github.com/louiscryan/hbase



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

[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500649#comment-14500649
 ] 

Lars Hofhansl commented on HBASE-10327:
---

With JDK 7 EOL'ing this very month I'd like to apply this to 0.98 (in a sub 
task). Any objections?

 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500673#comment-14500673
 ] 

Hadoop QA commented on HBASE-13481:
---

{color:green}+1 overall{color}.  Here are the results of testing the latest 
attachment 
  http://issues.apache.org/jira/secure/attachment/12726227/hbase-13481_v2.patch
  against master branch at commit 3ccae37866bde3783e1866ce92026a9410860515.
  ATTACHMENT ID: 12726227

{color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

{color:green}+1 tests included{color}.  The patch appears to include 3 new 
or modified tests.

{color:green}+1 hadoop versions{color}. The patch compiles with all 
supported hadoop versions (2.4.1 2.5.2 2.6.0)

{color:green}+1 javac{color}.  The applied patch does not increase the 
total number of javac compiler warnings.

{color:green}+1 protoc{color}.  The applied patch does not increase the 
total number of protoc compiler warnings.

{color:green}+1 javadoc{color}.  The javadoc tool did not generate any 
warning messages.

{color:green}+1 checkstyle{color}.  The applied patch does not increase the 
total number of checkstyle errors

{color:green}+1 findbugs{color}.  The patch does not introduce any  new 
Findbugs (version 2.0.3) warnings.

{color:green}+1 release audit{color}.  The applied patch does not increase 
the total number of release audit warnings.

{color:green}+1 lineLengths{color}.  The patch does not introduce lines 
longer than 100

  {color:green}+1 site{color}.  The mvn site goal succeeds with this patch.

{color:green}+1 core tests{color}.  The patch passed unit tests in .

Test results: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13736//testReport/
Release Findbugs (version 2.0.3)warnings: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13736//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13736//artifact/patchprocess/checkstyle-aggregate.html

  Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/13736//console

This message is automatically generated.

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-11290) Unlock RegionStates

[
https://issues.apache.org/jira/browse/HBASE-11290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500671#comment-14500671
]

Mikhail Antonov commented on HBASE-11290:
-

I'm thinking to resurrect this patch, as lots of time and effort seem to have
been invested in that.

[~virag], [~toffer], [~apurtell] - what do you guys think? Switching to IdLock
could be easier improvement here, or probably be done in subsequent patch?

What I'm thinking need to be clarified in latest version of patch is what's the
eviction policy of LockCache?

bq. We need to evict elements otherwise the map may grow unbounded.
But we can't evict element if it's being used as a lock key, right? Perhaps we
should have upper bound on number of locks held at any time and reject new
acquire() call if this limit is reached?

Unlock RegionStates
---

Key: HBASE-11290
URL: https://issues.apache.org/jira/browse/HBASE-11290
Project: HBase
Issue Type: Sub-task
Reporter: Francis Liu
Assignee: Virag Kothari
Fix For: 2.0.0, 1.1.0, 0.98.13

Attachments: HBASE-11290-0.98.patch, HBASE-11290-0.98_v2.patch,
HBASE-11290.draft.patch

Even though RegionStates is a highly accessed data structure in HMaster. Most
of it's methods are synchronized. Which limits concurrency. Even simply
making some of the getters non-synchronized by using concurrent data
structures has helped with region assignments. We can go as simple as this
approach or create locks per region or a bucket lock per region bucket.

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

[jira] [Commented] (HBASE-13494) 0.98: Remove remove(K, V) from type PoolMapK,V

2015-04-17 Thread Andrew Purtell (JIRA)


[ 
https://issues.apache.org/jira/browse/HBASE-13494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500696#comment-14500696
 ] 

Andrew Purtell commented on HBASE-13494:


+1

 0.98: Remove remove(K, V) from type PoolMapK,V
 

 Key: HBASE-13494
 URL: https://issues.apache.org/jira/browse/HBASE-13494
 Project: HBase
  Issue Type: Sub-task
Reporter: Lars Hofhansl
 Fix For: 0.98.13


 JDK7 will be EOL'ed this month. 0.98 should build with JDK8.
 [~apurtell] +1'd this in parent.
 Unless I hear objections I'll commit this later today.



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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500719#comment-14500719
 ] 

Enis Soztutar commented on HBASE-13481:
---

Thanks [~jerryhe], [~esteban] any more concerns? I would like to get this 
committed and spin up next RC for 1.0.1 today if possible.  

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-13481) Master should respect master (old) DNS/bind related configurations


[ 
https://issues.apache.org/jira/browse/HBASE-13481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500735#comment-14500735
 ] 

Esteban Gutierrez commented on HBASE-13481:
---

Same thing that [~jerryhe] noticed.  Otherwise +1.

 Master should respect master (old) DNS/bind related configurations
 --

 Key: HBASE-13481
 URL: https://issues.apache.org/jira/browse/HBASE-13481
 Project: HBase
  Issue Type: Sub-task
Reporter: Enis Soztutar
Assignee: Enis Soztutar
 Fix For: 2.0.0, 1.0.1, 1.1.0

 Attachments: hbase-13481_v1.patch, hbase-13481_v2.patch


 This is a continuation of parent HBASE-13453. We should continue respecting 
 the following parameters that 1.0.0 does not: 
 {code}
 hbase.master.dns.interface
 hbase.master.dns.nameserver
 hbase.master.ipc.address
 {code}
 Credit goes to [~jerryhe] for pointing that out. 



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

[jira] [Commented] (HBASE-10800) Use CellComparator instead of KVComparator

[
https://issues.apache.org/jira/browse/HBASE-10800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500738#comment-14500738
]

stack commented on HBASE-10800:
---

I finally got through the seven pages of patch. There are some concerns posted
on RB. Patch is too big. Comments are too many up on rb. Will be hard to ensure
all addressed in subsequent versions of the patch.

Here is a overarching comment from rb:

{quote}This is a fundamental change... Previous, the comparator knew about the
serialization and exploited this fact avoiding re-parse of KV part lengths and
offsets. In this patch we are moving the comparator to go via the Cell
Interface only it does not expose speedup methods, those methods that allow you
pass in a length or offset already calculated. While this patch preserves these
'carry-over' methods, they'll have to be removed eventually... the carry-over
methods just won't work when we have a different Cell type. So, we will see
slowdown comparing unless the Cell internally does what these carry-over
methods are doing and keeps them cached internally (HBASE-13448){quote}

Use CellComparator instead of KVComparator
--

Key: HBASE-10800
URL: https://issues.apache.org/jira/browse/HBASE-10800
Project: HBase
Issue Type: Sub-task
Reporter: ramkrishna.s.vasudevan
Assignee: ramkrishna.s.vasudevan
Fix For: 2.0.0

Attachments: HBASE-10800_1.patch, HBASE-10800_11.patch,
HBASE-10800_12.patch, HBASE-10800_13.patch, HBASE-10800_14.patch,
HBASE-10800_15.patch, HBASE-10800_16.patch, HBASE-10800_18.patch,
HBASE-10800_2.patch, HBASE-10800_3.patch, HBASE-10800_4.patch,
HBASE-10800_4.patch, HBASE-10800_5.patch, HBASE-10800_6.patch,
HBASE-10800_7.patch

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

[jira] [Created] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures

Esteban Gutierrez created HBASE-13495:
-

 Summary: Create metrics for purged calls, abandoned calls and 
other RPC failures
 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Bug
Reporter: Esteban Gutierrez


Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
calls are abandoned, purged and other states before the call is executed. This 
would be helpful to track the rate of channel closed exceptions when 100s or 
1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Comment Edited] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500649#comment-14500649
 ] 

Lars Hofhansl edited comment on HBASE-10327 at 4/17/15 8:53 PM:


With JDK 7 EOL'ing this very month I'd like to apply this to 0.98 (in a sub 
task). Any objections?
[~apurtell], [~stack]


was (Author: lhofhansl):
With JDK 7 EOL'ing this very month I'd like to apply this to 0.98 (in a sub 
task). Any objections?

 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Commented] (HBASE-13351) Annotate internal MasterRpcServices methods with admin priority


[ 
https://issues.apache.org/jira/browse/HBASE-13351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500691#comment-14500691
 ] 

Mikhail Antonov commented on HBASE-13351:
-

+1 (non-binding), long-awaited green run.

I'm not exactly sure if the build took longer (2 hr 40m) as a direct result of 
that or due to some other reason, but in any case, tests were going to be 
affected somewhat by this change.

 Annotate internal MasterRpcServices methods with admin priority
 ---

 Key: HBASE-13351
 URL: https://issues.apache.org/jira/browse/HBASE-13351
 Project: HBase
  Issue Type: Improvement
  Components: master
Reporter: Josh Elser
Assignee: Josh Elser
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13351-v1.patch, HBASE-13351-v2.patch, 
 HBASE-13351-v3.patch, HBASE-13351-v4.patch, HBASE-13351-v5.patch, 
 HBASE-13351.patch


 HBASE-12071, among other things, introduced annotating RPC methods to give 
 certain methods priority over others. Namely, this helps ensure that client 
 requests cannot starve out internal RPC between master and regionserver.
 Similarly, we can do the same thing for Master RPC methods that are invoked 
 by RS's.



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

[jira] [Commented] (HBASE-13456) Improve HFilePrettyPrinter first hbase:meta region processing


[ 
https://issues.apache.org/jira/browse/HBASE-13456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500730#comment-14500730
 ] 

Hudson commented on HBASE-13456:


SUCCESS: Integrated in HBase-TRUNK #6386 (See 
[https://builds.apache.org/job/HBase-TRUNK/6386/])
HBASE-13456 Improve HFilePrettyPrinter first hbase:meta region processing 
(Samir Ahmic) (jerryjch: rev 3ccae37866bde3783e1866ce92026a9410860515)
* hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/HFile.java


 Improve HFilePrettyPrinter first hbase:meta region processing 
 --

 Key: HBASE-13456
 URL: https://issues.apache.org/jira/browse/HBASE-13456
 Project: HBase
  Issue Type: Improvement
  Components: util
Affects Versions: 2.0.0, 0.98.12
 Environment: x86_64 GNU/Linux
Reporter: Samir Ahmic
Assignee: Samir Ahmic
Priority: Minor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13456-0.98-v2.patch, HBASE-13456-0.98.patch, 
 HBASE-13456-master-v2.patch, HBASE-13456-master.patch


 HFilePrettyPrinter have couple of small issues when -r option is used with 
 hbase:meta region as argument:
 1. Processing files in oldWals and recovered.edits directories
 {code}
 $ hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1
 Number of region files found - 3
 Found file[1] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Found file[2] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Found file[3] - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e1d395908f8c43d2b22bb3a630728ebf
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/info/e30faa185198449b9cb2eeb5589ebd1b
 Scanning - 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 2015-04-13 14:08:21,461 ERROR [main] hfile.HFilePrettyPrinter: Error reading 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile 
 Trailer from file 
 hdfs://P3cluster/hbase/data/hbase/meta/1588230740/oldWALs/hlog.1428309293399
 {code}
 2. If full region name is passed as argument we have wrong encoded region 
 name returned:
 {code}
 hbase org.apache.hadoop.hbase.io.hfile.HFilePrettyPrinter -v -r 
 hbase:meta,,1.1588230740
 region dir - hdfs://P3cluster/hbase/data/hbase/meta/104563571
 2015-04-13 14:21:43,012 INFO  [main] Configuration.deprecation: 
 hadoop.native.lib is deprecated. Instead, use io.native.lib.available
 2015-04-13 14:21:43,711 INFO  [main] util.ChecksumType: Checksum using 
 org.apache.hadoop.util.PureJavaCrc32
 2015-04-13 14:21:43,717 INFO  [main] util.ChecksumType: Checksum can use 
 org.apache.hadoop.util.PureJavaCrc32C
 2015-04-13 14:21:43,899 ERROR [main] hfile.HFilePrettyPrinter: Error parsing 
 command-line options
 java.io.FileNotFoundException: File 
 hdfs://P3cluster/hbase/data/hbase/meta/104563571 does not exist.
 {code}
 I have modified HFilePrettyPrinter.java to address this issues. Patch is 
 coming soon.



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

[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500747#comment-14500747
 ] 

stack commented on HBASE-10327:
---

This was only deprecated in 0.98. This is a breaking change.  Need to mark it 
as so.  Also believe no external users and given how late this is in the 0.98 
line with a 1.0 available, think it is ok to commit. Needs fat release note too.

 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Commented] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures


[ 
https://issues.apache.org/jira/browse/HBASE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500786#comment-14500786
 ] 

Mikhail Antonov commented on HBASE-13495:
-

Btw..In HBASE-13351 I mentioned possibility of adding metrics to see what 
percent of calls were made with with QoS priority (hence, executed by which 
thread pool). Do you think it's something that might be useful? 

 Create metrics for purged calls, abandoned calls and other RPC failures
 ---

 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez

 Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
 calls are abandoned, purged and other states before the call is executed. 
 This would be helpful to track the rate of channel closed exceptions when 
 100s or 1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Commented] (HBASE-13477) Create metrics on failed requests


[ 
https://issues.apache.org/jira/browse/HBASE-13477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500797#comment-14500797
 ] 

Nick Dimiduk commented on HBASE-13477:
--

+1.

Nit: would be cool if exception types could be counted dynamically, instead of 
limiting to these expected exceptions.

 Create metrics on failed requests
 -

 Key: HBASE-13477
 URL: https://issues.apache.org/jira/browse/HBASE-13477
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13477-v1.patch, HBASE-13477-v2.patch, 
 HBASE-13477-v3.patch, HBASE-13477.patch


 Add a metric on how many requests failed/errored out.



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

[jira] [Commented] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures


[ 
https://issues.apache.org/jira/browse/HBASE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500809#comment-14500809
 ] 

Mikhail Antonov commented on HBASE-13495:
-

Sure, just wanted to ask for another opinion as the topic seems closed. Sorry 
for some offtopic.

 Create metrics for purged calls, abandoned calls and other RPC failures
 ---

 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez

 Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
 calls are abandoned, purged and other states before the call is executed. 
 This would be helpful to track the rate of channel closed exceptions when 
 100s or 1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Commented] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures


[ 
https://issues.apache.org/jira/browse/HBASE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500808#comment-14500808
 ] 

Esteban Gutierrez commented on HBASE-13495:
---

[~mantonov] Yeah, the points you bring in HBASE-13351 are important for 
production environments, I think we can piggyback on this but ideally we should 
have another JIRA, rigth?

 Create metrics for purged calls, abandoned calls and other RPC failures
 ---

 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez

 Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
 calls are abandoned, purged and other states before the call is executed. 
 This would be helpful to track the rate of channel closed exceptions when 
 100s or 1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Updated] (HBASE-13477) Create metrics on failed requests


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

Elliott Clark updated HBASE-13477:
--
  Resolution: Fixed
Hadoop Flags: Reviewed
  Status: Resolved  (was: Patch Available)

Thanks everyone

 Create metrics on failed requests
 -

 Key: HBASE-13477
 URL: https://issues.apache.org/jira/browse/HBASE-13477
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13477-v1.patch, HBASE-13477-v2.patch, 
 HBASE-13477-v3.patch, HBASE-13477.patch


 Add a metric on how many requests failed/errored out.



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

[jira] [Commented] (HBASE-10327) Remove remove(K, V) from type PoolMapK,V


[ 
https://issues.apache.org/jira/browse/HBASE-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500832#comment-14500832
 ] 

Lars Hofhansl commented on HBASE-10327:
---

It was deprecated in 0.98.0 and this is a class marked Private; so I do not 
think we're breaking any of our promises.
I'll add a release note, just in case.


 Remove remove(K, V) from type PoolMapK,V
 --

 Key: HBASE-10327
 URL: https://issues.apache.org/jira/browse/HBASE-10327
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.99.0
Reporter: Eric Charles
Assignee: Eric Charles
 Fix For: 0.99.0

 Attachments: HBASE-10327.patch


 I keep getting red cross in my eclipse, whatever the jdk (jdk6, jdk7, jdk8)
 Name clash: The method remove(K, V) of type PoolMapK,V has the same erasure 
 as remove(Object, Object) of type MapK,V but does not override it
 maybe related to HBASE-10030
 The solution I have is simply removing the deprecated method, and everything 
 is fine. I am not sure of the backwards compatibility here.



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

[jira] [Updated] (HBASE-13090) Progress heartbeats for long running scanners


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

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

Pushed to branch-1, branch-1.1, and master.  [~ndimiduk] I pushed it since you 
seem to want it. Patch looks good to me and we'll be running tests over next 
week or so so if issue it'll turn up... Thanks.

Thanks for the patch [~jonathan.lawlor]

 Progress heartbeats for long running scanners
 -

 Key: HBASE-13090
 URL: https://issues.apache.org/jira/browse/HBASE-13090
 Project: HBase
  Issue Type: New Feature
Reporter: Andrew Purtell
Assignee: Jonathan Lawlor
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13090-v1.patch, HBASE-13090-v2.patch, 
 HBASE-13090-v3.patch, HBASE-13090-v3.patch, HBASE-13090-v4.patch, 
 HBASE-13090-v6.patch, HBASE-13090-v7.patch


 It can be necessary to set very long timeouts for clients that issue scans 
 over large regions when all data in the region might be filtered out 
 depending on scan criteria. This is a usability concern because it can be 
 hard to identify what worst case timeout to use until scans are 
 occasionally/intermittently failing in production, depending on variable scan 
 criteria. It would be better if the client-server scan protocol can send back 
 periodic progress heartbeats to clients as long as server scanners are alive 
 and making progress.
 This is related but orthogonal to streaming scan (HBASE-13071). 



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

[jira] [Updated] (HBASE-13494) 0.98: Remove remove(K, V) from type PoolMapK,V


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

Lars Hofhansl updated HBASE-13494:
--
Release Note: 
This removes PoolMap.remove(K key, V value).
Callers using this method must use PoolMap.removeValue(K key, V value) instead.

 0.98: Remove remove(K, V) from type PoolMapK,V
 

 Key: HBASE-13494
 URL: https://issues.apache.org/jira/browse/HBASE-13494
 Project: HBase
  Issue Type: Sub-task
Reporter: Lars Hofhansl
 Fix For: 0.98.13


 JDK7 will be EOL'ed this month. 0.98 should build with JDK8.
 [~apurtell] +1'd this in parent.
 Unless I hear objections I'll commit this later today.



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

[jira] [Commented] (HBASE-13389) [REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations

[
https://issues.apache.org/jira/browse/HBASE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500883#comment-14500883
]

Lars Hofhansl commented on HBASE-13389:
---

Sure. After discussions we had ([~stack], [~apurtell], and I) I think we can
reinstate my original code, where we check against the oldest running scanner
and if all Cell in an HFile are older than that scaner (in terms of MVCC
timestamp) we can set them to 0 and not store them upon compaction.

The observation being that we only need MVCC stamps in the HFile to cover
flushes/compactions that happen while a current scanner is running.
All other cases we should be covering with metadata in the HFiles trailer, not
on individual Cells.

[~jeffreyz], do you agree? HBASE-12600 changed that, and I bet you had a very
good reason.

[REGRESSION] HBASE-12600 undoes skip-mvcc parse optimizations
-

Key: HBASE-13389
URL: https://issues.apache.org/jira/browse/HBASE-13389
Project: HBase
Issue Type: Sub-task
Components: Performance
Reporter: stack
Attachments: 13389.txt

HBASE-12600 moved the edit sequenceid from tags to instead exploit the
mvcc/sequenceid slot in a key. Now Cells near-always have an associated
mvcc/sequenceid where previous it was rare or the mvcc was kept up at the
file level. This is sort of how it should be many of us would argue but as a
side-effect of this change, read-time optimizations that helped speed scans
were undone by this change.
In this issue, lets see if we can get the optimizations back -- or just
remove the optimizations altogether.
The parse of mvcc/sequenceid is expensive. It was noticed over in HBASE-13291.
The optimizations undone by this changes are (to quote the optimizer himself,
Mr [~lhofhansl]):
{quote}
Looks like this undoes all of HBASE-9751, HBASE-8151, and HBASE-8166.
We're always storing the mvcc readpoints, and we never compare them against
the actual smallestReadpoint, and hence we're always performing all the
checks, tests, and comparisons that these jiras removed in addition to
actually storing the data - which with up to 8 bytes per Cell is not trivial.
{quote}
This is the 'breaking' change:
https://github.com/apache/hbase/commit/2c280e62530777ee43e6148fd6fcf6dac62881c0#diff-07c7ac0a9179cedff02112489a20157fR96

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

[jira] [Commented] (HBASE-13495) Create metrics for purged calls, abandoned calls and other RPC failures


[ 
https://issues.apache.org/jira/browse/HBASE-13495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500799#comment-14500799
 ] 

Elliott Clark commented on HBASE-13495:
---

[~esteban] Sounds that would be very cool.

 Create metrics for purged calls, abandoned calls and other RPC failures
 ---

 Key: HBASE-13495
 URL: https://issues.apache.org/jira/browse/HBASE-13495
 Project: HBase
  Issue Type: Improvement
Reporter: Esteban Gutierrez
Assignee: Esteban Gutierrez

 Similar to HBASE-13477 this aimed to add metrics to keep track of how many 
 calls are abandoned, purged and other states before the call is executed. 
 This would be helpful to track the rate of channel closed exceptions when 
 100s or 1000s of clients disconnect or the calls are not correctly formed.



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

[jira] [Commented] (HBASE-13477) Create metrics on failed requests


[ 
https://issues.apache.org/jira/browse/HBASE-13477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14500806#comment-14500806
 ] 

Elliott Clark commented on HBASE-13477:
---

Yeah dynamic would be very cool, and it's possible however last time we put a 
hashmap into the metrics hot path it ended up taking a lot of cpu.
So I wanted to get this in and then we can see about perf for adding more

 Create metrics on failed requests
 -

 Key: HBASE-13477
 URL: https://issues.apache.org/jira/browse/HBASE-13477
 Project: HBase
  Issue Type: Bug
Affects Versions: 1.0.0, 2.0.0
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 2.0.0, 1.1.0

 Attachments: HBASE-13477-v1.patch, HBASE-13477-v2.patch, 
 HBASE-13477-v3.patch, HBASE-13477.patch


 Add a metric on how many requests failed/errored out.



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

[jira] [Assigned] (HBASE-13494) 0.98: Remove remove(K, V) from type PoolMapK,V