date:20120615


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

Zhihong Ted Yu commented on HBASE-6135:
---

The repeated failure of TestRSStatusServlet#testWithRegions seems to be related 
to this JIRA.

 Style the Web UI to use Twitter's Bootstrap.
 

 Key: HBASE-6135
 URL: https://issues.apache.org/jira/browse/HBASE-6135
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6135-0.patch, HBASE-6135-1.patch, 
 HBASE-6135-2.patch, HBASE-6135-3.patch, HBASE-6135-4.patch, 
 HBASE-6135-5.patch, master-redesign.png, redesign-master-r1.png, 
 redesign-rs-r1.png


 Our web ui has lagged a little bit behind.  While it's not a huge deal, it is 
 one of the first things that new people see.  As such styling it a little bit 
 better would put a good foot forward.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5564) Bulkload is discarding duplicate records

2012-06-15 Thread ramkrishna.s.vasudevan (JIRA)


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

ramkrishna.s.vasudevan updated HBASE-5564:
--

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

Committed to trunk.
Thanks for the patch Laxman.
Thanks for the review Stack, Ted, Lars, Todd, Jesse and Anoop.

 Bulkload is discarding duplicate records
 

 Key: HBASE-5564
 URL: https://issues.apache.org/jira/browse/HBASE-5564
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 0.96.0
 Environment: HBase 0.92
Reporter: Laxman
Assignee: Laxman
  Labels: bulkloader
 Fix For: 0.96.0

 Attachments: 5564.lint, 5564v5.txt, HBASE-5564.patch, 
 HBASE-5564_1.patch, HBASE-5564_trunk.1.patch, HBASE-5564_trunk.1.patch, 
 HBASE-5564_trunk.2.patch, HBASE-5564_trunk.3.patch, 
 HBASE-5564_trunk.4_final.patch, HBASE-5564_trunk.patch


 Duplicate records are getting discarded when duplicate records exists in same 
 input file and more specifically if they exists in same split.
 Duplicate records are considered if the records are from diffrent different 
 splits.
 Version under test: HBase 0.92

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6196) MR testcases TestImportExport does not run in Trunk with hadoop2.0

2012-06-15 Thread ramkrishna.s.vasudevan (JIRA)


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

ramkrishna.s.vasudevan commented on HBASE-6196:
---

Can some one check this mapreduce part? Am not very sure as what is happening 
here.

 MR testcases TestImportExport does not run in Trunk with hadoop2.0
 --

 Key: HBASE-6196
 URL: https://issues.apache.org/jira/browse/HBASE-6196
 Project: HBase
  Issue Type: Bug
Affects Versions: 0.94.0, 0.96.0
Reporter: ramkrishna.s.vasudevan
 Fix For: 0.96.0


 TEstImportExport test cases does not run in trunk when compiled with hadoop 
 2.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5564) Bulkload is discarding duplicate records


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

Hudson commented on HBASE-5564:
---

Integrated in HBase-TRUNK #3030 (See 
[https://builds.apache.org/job/HBase-TRUNK/3030/])
HBASE-5564 Bulkload is discarding duplicate records

Submitted by:Laxman 
Reviewed by:iStack, Ted, Ram (Revision 1350691)

 Result = FAILURE
ramkrishna : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/ImportTsv.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TsvImporterMapper.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportTsv.java


 Bulkload is discarding duplicate records
 

 Key: HBASE-5564
 URL: https://issues.apache.org/jira/browse/HBASE-5564
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 0.96.0
 Environment: HBase 0.92
Reporter: Laxman
Assignee: Laxman
  Labels: bulkloader
 Fix For: 0.96.0

 Attachments: 5564.lint, 5564v5.txt, HBASE-5564.patch, 
 HBASE-5564_1.patch, HBASE-5564_trunk.1.patch, HBASE-5564_trunk.1.patch, 
 HBASE-5564_trunk.2.patch, HBASE-5564_trunk.3.patch, 
 HBASE-5564_trunk.4_final.patch, HBASE-5564_trunk.patch


 Duplicate records are getting discarded when duplicate records exists in same 
 input file and more specifically if they exists in same split.
 Duplicate records are considered if the records are from diffrent different 
 splits.
 Version under test: HBase 0.92

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6215) per-request profiling

Kannan Muthukkaruppan created HBASE-6215:


 Summary: per-request profiling
 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan


Add ability to get HBase metrics back from an individual request. Apps can use 
this to track fine-grained metrics (such as server-side latency, block cache 
access/hit count; sync latency; append latency; etc.) on a per-API call basis. 
Also, enhance HBase shell to also support this feature. [For example, if in the 
shell we turn profiling on, for all subsequent requests the profiling stats 
will be pretty printed, or optionally written to a file.]


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6216) per-request tagging

Kannan Muthukkaruppan created HBASE-6216:


 Summary: per-request tagging
 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan


Allow applications to tag individual RPC requests so that metrics exposed by 
HBase can automatically be collected/aggregated by those tags. This'll be 
useful for problem diagnosis across various applications-- as it will allow us 
to correlate HBase metrics (such as data block misses) back to application 
level tags.

For example, in some multi-tenancy type use case where many different 
applications are served out of a single Table or CF, it'll be useful to know 
the break down of metrics (such as bytes read, data block misses, get/put RPC 
calls, etc.) by application name (tag).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6135) Style the Web UI to use Twitter's Bootstrap.


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

Elliott Clark updated HBASE-6135:
-

Attachment: HBASE-6135-ADD-0.patch

That test is pretty in-complete.  We should think about making the mocking a 
little more complete. Until then this should work.

 Style the Web UI to use Twitter's Bootstrap.
 

 Key: HBASE-6135
 URL: https://issues.apache.org/jira/browse/HBASE-6135
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6135-0.patch, HBASE-6135-1.patch, 
 HBASE-6135-2.patch, HBASE-6135-3.patch, HBASE-6135-4.patch, 
 HBASE-6135-5.patch, HBASE-6135-ADD-0.patch, master-redesign.png, 
 redesign-master-r1.png, redesign-rs-r1.png


 Our web ui has lagged a little bit behind.  While it's not a huge deal, it is 
 one of the first things that new people see.  As such styling it a little bit 
 better would put a good foot forward.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6066) some low hanging read path improvement ideas


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

Kannan Muthukkaruppan commented on HBASE-6066:
--

One of our interns (Aurick) is planning to work on this.

Part #3, the incrNumericMetric overhead patch is easier-- it is a slight 
variant of Todd's patch and should result in fewer AtomicLong operations 
because it just accumulates in a local variable and updates the counter at the 
end. It is part of a diff by Michael Chen: 
https://reviews.facebook.net/D3627#a83f6d09. I think it is better to fork off 
this part (#4) into its own JIRA and Aurick will work on the others.

 some low hanging read path improvement ideas 
 -

 Key: HBASE-6066
 URL: https://issues.apache.org/jira/browse/HBASE-6066
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Priority: Critical
  Labels: noob
 Attachments: metric-stringbuilder-fix.patch


 I was running some single threaded scan performance tests for a table with 
 small sized rows that is fully cached. Some observations...
 We seem to be doing several wasteful iterations over and/or building of 
 temporary lists.
 1) One such is the following code in HRegionServer.next():
 {code}
boolean moreRows = s.next(values, HRegion.METRIC_NEXTSIZE);
if (!values.isEmpty()) {
  for (KeyValue kv : values) {  --  wasteful in most 
 cases
currentScanResultSize += kv.heapSize();
}
results.add(new Result(values));
 {code}
 By default the maxScannerResultSize is Long.MAX_VALUE. In those cases,
 we can avoid the unnecessary iteration to compute currentScanResultSize.
 2) An example of a wasteful temporary array, is results in
 RegionScanner.next().
 {code}
   results.clear();
   boolean returnResult = nextInternal(limit, metric);
   outResults.addAll(results);
 {code}
 results then gets copied over to outResults via an addAll(). Not sure why we 
 can not directly collect the results in outResults.
 3) Another almost similar exmaple of a wasteful array is results in 
 StoreScanner.next(), which eventually also copies its results into 
 outResults.
 4) Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
   if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.
 5) RegionScanner.next() calls a helper RegionScanner.next() on the same 
 object. Both are synchronized methods. Synchronized methods calling nested 
 synchronized methods on the same object are probably adding some small 
 overhead. The inner next() calls isFilterDone() which is a also a 
 synchronized method. We should factor the code to avoid these nested 
 synchronized methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6217) reduce overhead of maintaing get/next size metric

Kannan Muthukkaruppan created HBASE-6217:


 Summary: reduce overhead of maintaing get/next size metric
 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan


[Forked off this specific issue as a separate JIRA from HBASE-6066].

Reduce overhead of size metric maintained in StoreScanner.next().

{code}
if (metric != null) {
 HRegion.incrNumericMetric(this.metricNamePrefix + metric,
   copyKv.getLength());
  }
  results.add(copyKv);
{code}

A single call to next() might fetch a lot of KVs. We can first add up the size 
of those KVs in a local variable and then in a finally clause increment the 
metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6205) Support an option to keep data of dropped table for some time


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

Zhihong Ted Yu commented on HBASE-6205:
---

@Stack:
Did Chunhui answer your question ?

 Support an option to keep data of dropped table for some time
 -

 Key: HBASE-6205
 URL: https://issues.apache.org/jira/browse/HBASE-6205
 Project: HBase
  Issue Type: New Feature
Affects Versions: 0.94.0, 0.96.0
Reporter: chunhui shen
Assignee: chunhui shen
 Fix For: 0.96.0

 Attachments: HBASE-6205.patch, HBASE-6205v2.patch, HBASE-6205v3.patch


 User may drop table accidentally because of error code or other uncertain 
 reasons.
 Unfortunately, it happens in our environment because one user make a mistake 
 between production cluster and testing cluster.
 So, I just give a suggestion, do we need to support an option to keep data of 
 dropped table for some time, e.g. 1 day
 In the patch:
 We make a new dir named .trashtables in the rood dir.
 In the DeleteTableHandler, we move files in dropped table's dir to trash 
 table dir instead of deleting them directly.
 And Create new class TrashCleaner which will clean dropped tables if it is 
 time out with a period check.
 Default keep time for dropped tables is 1 day, and check period is 1 hour.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6216) per-request tagging


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

Kannan Muthukkaruppan reassigned HBASE-6216:


Assignee: Aurick Qiao  (was: Kannan Muthukkaruppan)

 per-request tagging
 ---

 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Allow applications to tag individual RPC requests so that metrics exposed by 
 HBase can automatically be collected/aggregated by those tags. This'll be 
 useful for problem diagnosis across various applications-- as it will allow 
 us to correlate HBase metrics (such as data block misses) back to application 
 level tags.
 For example, in some multi-tenancy type use case where many different 
 applications are served out of a single Table or CF, it'll be useful to know 
 the break down of metrics (such as bytes read, data block misses, get/put RPC 
 calls, etc.) by application name (tag).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6215) per-request profiling


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

Kannan Muthukkaruppan reassigned HBASE-6215:


Assignee: Aurick Qiao  (was: Kannan Muthukkaruppan)

 per-request profiling
 -

 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Add ability to get HBase metrics back from an individual request. Apps can 
 use this to track fine-grained metrics (such as server-side latency, block 
 cache access/hit count; sync latency; append latency; etc.) on a per-API call 
 basis. Also, enhance HBase shell to also support this feature. [For example, 
 if in the shell we turn profiling on, for all subsequent requests the 
 profiling stats will be pretty printed, or optionally written to a file.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6162) Move KeyValue to hbase-common module

2012-06-15 Thread Matt Corgan (JIRA)


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

Matt Corgan commented on HBASE-6162:


No worries stack - i just wasn't sure of the best approach for the tests so 
decided to punt for now.  I think we all agree they would be best in 
hbase-common/src/test/java, but are foiled by maven again.  

I actually tried putting them in 
hbase-common/src/main/java/org/apache/hbase/test (removed hadoop package), but 
it made for a very confusing package tree in eclipse since the non-test classes 
were still in org/apache/hadoop/hbase.  Looking at it made me think we should 
drop the hadoop package for everything all at once and not move things 
peicemeal.

It would be nice to pull the tests up somehow to help us untangle things... 
what do you think is the best approach now?  I can live with new modules, funny 
package trees, etc.  Just need to pick our poison i guess.  I unfortunately 
don't know enough about maven to even make a suggestion.  You thinking an 
hbase-common-tests module is the best approach for now?

 Move KeyValue to hbase-common module
 

 Key: HBASE-6162
 URL: https://issues.apache.org/jira/browse/HBASE-6162
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.96.0
Reporter: Matt Corgan
Assignee: Matt Corgan
 Fix For: 0.96.0

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


 * pull KeyValue up to hbase-common module
 This is part of the modularization strategy in HBASE-5977, and is 
 specifically necessary to modularize HBASE-4676.
 also brings these classes to hbase-common:
 * ClassSize, HeapSize
 * HTestConst
 * TestKeyValue, KeyValueTestUtil
 * LoadTestKVGenerator, TestLoadTestKVGenerator
 * MD5Hash
 moves a trivial constant (HRegionInfo.DELIMITER) from HRegionInfo to 
 HConstants

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6135) Style the Web UI to use Twitter's Bootstrap.


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

Zhihong Ted Yu commented on HBASE-6135:
---

Addendum integrated to trunk.

 Style the Web UI to use Twitter's Bootstrap.
 

 Key: HBASE-6135
 URL: https://issues.apache.org/jira/browse/HBASE-6135
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6135-0.patch, HBASE-6135-1.patch, 
 HBASE-6135-2.patch, HBASE-6135-3.patch, HBASE-6135-4.patch, 
 HBASE-6135-5.patch, HBASE-6135-ADD-0.patch, master-redesign.png, 
 redesign-master-r1.png, redesign-rs-r1.png


 Our web ui has lagged a little bit behind.  While it's not a huge deal, it is 
 one of the first things that new people see.  As such styling it a little bit 
 better would put a good foot forward.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Attachment: StoreScanner.java

Use a local variable to keep track of changes to the metrics and apply the 
changes all at once.

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan
 Attachments: StoreScanner.java


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6216) per-request tagging


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

Kannan Muthukkaruppan reassigned HBASE-6216:


Assignee: M. Chen  (was: Aurick Qiao)

 per-request tagging
 ---

 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen

 Allow applications to tag individual RPC requests so that metrics exposed by 
 HBase can automatically be collected/aggregated by those tags. This'll be 
 useful for problem diagnosis across various applications-- as it will allow 
 us to correlate HBase metrics (such as data block misses) back to application 
 level tags.
 For example, in some multi-tenancy type use case where many different 
 applications are served out of a single Table or CF, it'll be useful to know 
 the break down of metrics (such as bytes read, data block misses, get/put RPC 
 calls, etc.) by application name (tag).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6135) Style the Web UI to use Twitter's Bootstrap.


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

Hudson commented on HBASE-6135:
---

Integrated in HBase-TRUNK #3031 (See 
[https://builds.apache.org/job/HBase-TRUNK/3031/])
HBASE-6135 Style the Web UI to use Twitter's Bootstrap, addendum (Elliot 
Clark)

Submitted by:   Elliot Clark
Reviewed by:Ted Yu (Revision 1350731)

 Result = FAILURE
tedyu : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RegionListTmpl.jamon


 Style the Web UI to use Twitter's Bootstrap.
 

 Key: HBASE-6135
 URL: https://issues.apache.org/jira/browse/HBASE-6135
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6135-0.patch, HBASE-6135-1.patch, 
 HBASE-6135-2.patch, HBASE-6135-3.patch, HBASE-6135-4.patch, 
 HBASE-6135-5.patch, HBASE-6135-ADD-0.patch, master-redesign.png, 
 redesign-master-r1.png, redesign-rs-r1.png


 Our web ui has lagged a little bit behind.  While it's not a huge deal, it is 
 one of the first things that new people see.  As such styling it a little bit 
 better would put a good foot forward.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6066) some low hanging read path improvement ideas


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

Kannan Muthukkaruppan reassigned HBASE-6066:


Assignee: Kannan Muthukkaruppan

 some low hanging read path improvement ideas 
 -

 Key: HBASE-6066
 URL: https://issues.apache.org/jira/browse/HBASE-6066
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan
Priority: Critical
  Labels: noob
 Attachments: metric-stringbuilder-fix.patch


 I was running some single threaded scan performance tests for a table with 
 small sized rows that is fully cached. Some observations...
 We seem to be doing several wasteful iterations over and/or building of 
 temporary lists.
 1) One such is the following code in HRegionServer.next():
 {code}
boolean moreRows = s.next(values, HRegion.METRIC_NEXTSIZE);
if (!values.isEmpty()) {
  for (KeyValue kv : values) {  --  wasteful in most 
 cases
currentScanResultSize += kv.heapSize();
}
results.add(new Result(values));
 {code}
 By default the maxScannerResultSize is Long.MAX_VALUE. In those cases,
 we can avoid the unnecessary iteration to compute currentScanResultSize.
 2) An example of a wasteful temporary array, is results in
 RegionScanner.next().
 {code}
   results.clear();
   boolean returnResult = nextInternal(limit, metric);
   outResults.addAll(results);
 {code}
 results then gets copied over to outResults via an addAll(). Not sure why we 
 can not directly collect the results in outResults.
 3) Another almost similar exmaple of a wasteful array is results in 
 StoreScanner.next(), which eventually also copies its results into 
 outResults.
 4) Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
   if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.
 5) RegionScanner.next() calls a helper RegionScanner.next() on the same 
 object. Both are synchronized methods. Synchronized methods calling nested 
 synchronized methods on the same object are probably adding some small 
 overhead. The inner next() calls isFilterDone() which is a also a 
 synchronized method. We should factor the code to avoid these nested 
 synchronized methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6216) per-request tagging


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

Kannan Muthukkaruppan reassigned HBASE-6216:


Assignee: Kannan Muthukkaruppan  (was: M. Chen)

 per-request tagging
 ---

 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Kannan Muthukkaruppan

 Allow applications to tag individual RPC requests so that metrics exposed by 
 HBase can automatically be collected/aggregated by those tags. This'll be 
 useful for problem diagnosis across various applications-- as it will allow 
 us to correlate HBase metrics (such as data block misses) back to application 
 level tags.
 For example, in some multi-tenancy type use case where many different 
 applications are served out of a single Table or CF, it'll be useful to know 
 the break down of metrics (such as bytes read, data block misses, get/put RPC 
 calls, etc.) by application name (tag).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6216) per-request tagging


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

Kannan Muthukkaruppan reassigned HBASE-6216:


Assignee: Aurick Qiao  (was: Kannan Muthukkaruppan)

accidentally assigned the wrong JIRA to Michael.

 per-request tagging
 ---

 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Allow applications to tag individual RPC requests so that metrics exposed by 
 HBase can automatically be collected/aggregated by those tags. This'll be 
 useful for problem diagnosis across various applications-- as it will allow 
 us to correlate HBase metrics (such as data block misses) back to application 
 level tags.
 For example, in some multi-tenancy type use case where many different 
 applications are served out of a single Table or CF, it'll be useful to know 
 the break down of metrics (such as bytes read, data block misses, get/put RPC 
 calls, etc.) by application name (tag).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6066) some low hanging read path improvement ideas


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

Kannan Muthukkaruppan reassigned HBASE-6066:


Assignee: Aurick Qiao  (was: Kannan Muthukkaruppan)

 some low hanging read path improvement ideas 
 -

 Key: HBASE-6066
 URL: https://issues.apache.org/jira/browse/HBASE-6066
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao
Priority: Critical
  Labels: noob
 Attachments: metric-stringbuilder-fix.patch


 I was running some single threaded scan performance tests for a table with 
 small sized rows that is fully cached. Some observations...
 We seem to be doing several wasteful iterations over and/or building of 
 temporary lists.
 1) One such is the following code in HRegionServer.next():
 {code}
boolean moreRows = s.next(values, HRegion.METRIC_NEXTSIZE);
if (!values.isEmpty()) {
  for (KeyValue kv : values) {  --  wasteful in most 
 cases
currentScanResultSize += kv.heapSize();
}
results.add(new Result(values));
 {code}
 By default the maxScannerResultSize is Long.MAX_VALUE. In those cases,
 we can avoid the unnecessary iteration to compute currentScanResultSize.
 2) An example of a wasteful temporary array, is results in
 RegionScanner.next().
 {code}
   results.clear();
   boolean returnResult = nextInternal(limit, metric);
   outResults.addAll(results);
 {code}
 results then gets copied over to outResults via an addAll(). Not sure why we 
 can not directly collect the results in outResults.
 3) Another almost similar exmaple of a wasteful array is results in 
 StoreScanner.next(), which eventually also copies its results into 
 outResults.
 4) Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
   if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.
 5) RegionScanner.next() calls a helper RegionScanner.next() on the same 
 object. Both are synchronized methods. Synchronized methods calling nested 
 synchronized methods on the same object are probably adding some small 
 overhead. The inner next() calls isFilterDone() which is a also a 
 synchronized method. We should factor the code to avoid these nested 
 synchronized methods.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Assigned] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

Kannan Muthukkaruppan reassigned HBASE-6217:


Assignee: M. Chen  (was: Kannan Muthukkaruppan)

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
 Attachments: StoreScanner.java


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6213) Add metrics for the number of blocks in cache per CF and block type

2012-06-15 Thread Mikhail Bautin (JIRA)


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

Mikhail Bautin updated HBASE-6213:
--

Assignee: Mikhail Bautin

 Add metrics for the number of blocks in cache per CF and block type
 ---

 Key: HBASE-6213
 URL: https://issues.apache.org/jira/browse/HBASE-6213
 Project: HBase
  Issue Type: Improvement
Reporter: Mikhail Bautin
Assignee: Mikhail Bautin
Priority: Minor

 We need to know the number of blocks in cache per CF/block type, not just the 
 total size of all blocks of the given type, in order to measure data block 
 encoding efficiency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen commented on HBASE-6217:


Diff uploaded at https://reviews.facebook.net/differential/diff/11895

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
 Attachments: StoreScanner.java


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen commented on HBASE-6217:


latest: https://reviews.facebook.net/differential/diff/11907

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
 Attachments: StoreScanner.java


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6215) per-request profiling

2012-06-15 Thread Todd Lipcon (JIRA)


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

Todd Lipcon commented on HBASE-6215:


Hey Kannan. We have an intern here who is also working on something similar to 
this. Do you have any docs on the plan? Would be good to collaborate where 
possible.

 per-request profiling
 -

 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Add ability to get HBase metrics back from an individual request. Apps can 
 use this to track fine-grained metrics (such as server-side latency, block 
 cache access/hit count; sync latency; append latency; etc.) on a per-API call 
 basis. Also, enhance HBase shell to also support this feature. [For example, 
 if in the shell we turn profiling on, for all subsequent requests the 
 profiling stats will be pretty printed, or optionally written to a file.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6215) per-request profiling

2012-06-15 Thread Aurick Qiao (JIRA)


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

Aurick Qiao commented on HBASE-6215:


I already have a working implementation of the feature, although not very well 
tested yet. I can upload a diff if you want.

 per-request profiling
 -

 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Add ability to get HBase metrics back from an individual request. Apps can 
 use this to track fine-grained metrics (such as server-side latency, block 
 cache access/hit count; sync latency; append latency; etc.) on a per-API call 
 basis. Also, enhance HBase shell to also support this feature. [For example, 
 if in the shell we turn profiling on, for all subsequent requests the 
 profiling stats will be pretty printed, or optionally written to a file.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6188) Remove the concept of table owner

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

Andrew Purtell commented on HBASE-6188:
---

TestAccessController doesn't pass for me.

The new code in postCreateTable must make a special case for the ACL table.
It's not possible to call AccessControlLists.addUserPermission before the ACL
table is deployed, i.e. created.

Remove the concept of table owner
-

Key: HBASE-6188
URL: https://issues.apache.org/jira/browse/HBASE-6188
Project: HBase
Issue Type: Sub-task
Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Laxman
Labels: security
Fix For: 0.96.0, 0.94.1

Attachments: HBASE-6188.1.patch, HBASE-6188.2.patch, HBASE-6188.patch

The table owner concept was a design simplification in the initial drop.
First, the design changes under review means only a user with GLOBAL CREATE
permission can create a table, which will probably be an administrator.
Then, granting implicit permissions may lead to oversights and it adds
unnecessary conditionals to our code. So instead the administrator with
GLOBAL CREATE permission should make the appropriate grants at table create
time.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-4391) Add ability to start RS as root and call mlockall

2012-06-15 Thread Matteo Bertozzi (JIRA)


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

Matteo Bertozzi updated HBASE-4391:
---

Attachment: HBASE-4391-v1.patch

Moved to src/main/native as Andrew suggested

 Add ability to start RS as root and call mlockall
 -

 Key: HBASE-4391
 URL: https://issues.apache.org/jira/browse/HBASE-4391
 Project: HBase
  Issue Type: New Feature
  Components: regionserver
Affects Versions: 0.94.0
Reporter: Todd Lipcon
Assignee: Todd Lipcon
 Fix For: 0.96.0

 Attachments: HBASE-4391-v0.patch, HBASE-4391-v1.patch


 A common issue we've seen in practice is that users oversubscribe their 
 region servers with too many MR tasks, etc. As soon as the machine starts 
 swapping, the RS grinds to a halt, loses ZK session, aborts, etc.
 This can be combatted by starting the RS as root, calling mlockall(), and 
 then setuid down to the hbase user. We should not require this, but we should 
 provide it as an option.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6218) Add dynamic on/off tracing facility to regionserver; lightweight(?) record of read/write load

2012-06-15 Thread stack (JIRA)

stack created HBASE-6218:


 Summary: Add dynamic on/off tracing facility to regionserver; 
lightweight(?) record of read/write load
 Key: HBASE-6218
 URL: https://issues.apache.org/jira/browse/HBASE-6218
 Project: HBase
  Issue Type: New Feature
  Components: test
Reporter: stack


It'd be sweet if we could kick a regionserver and have it start recording the 
read/write load.  Then after we'd taken a sample, we could turn off the 
recording.

Chatting at the meetup today, replaying the WALs would give you the write side 
(though missing would be the rate at which the client should play the edits -- 
perhaps we could add this to the WALEdit if its not already there?).

Read side we'd need something new recording the read load (Perhaps we'd have a 
single trace for read and write but somehow you could get the write from the 
WAL logs).  It would be nice too if we could verify that we read the right 
thing somehow (hash of the return when the trace switch is thrown?  Would need 
to cater to differences in timestamp possibly?)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6215) per-request profiling

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

Kannan Muthukkaruppan commented on HBASE-6215:
--

@ There's change to the RPC (that might be specific to 89-fb, given that trunk
has moved on to PB). And the changes to the server side, i.e. what stats we
collect and send back could likely be largely shared. In step 1, Aurick has
focused on the first part and is now starting to look at the specific metrics
we want to send back as the next step. Makes sense to discuss/collaborate on
the ideas.

per-request profiling
-

Key: HBASE-6215
URL: https://issues.apache.org/jira/browse/HBASE-6215
Project: HBase
Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

Add ability to get HBase metrics back from an individual request. Apps can
use this to track fine-grained metrics (such as server-side latency, block
cache access/hit count; sync latency; append latency; etc.) on a per-API call
basis. Also, enhance HBase shell to also support this feature. [For example,
if in the shell we turn profiling on, for all subsequent requests the
profiling stats will be pretty printed, or optionally written to a file.]

[jira] [Updated] (HBASE-6215) per-request profiling


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

Kannan Muthukkaruppan updated HBASE-6215:
-

Description: 
Add ability to get HBase metrics back from an individual request. Apps can use 
this to track fine-grained metrics (such as server-side latency, block cache 
access/hit count; sync latency; append latency; etc.) on a per-API call basis. 
Also, enhance HBase shell to support this feature. [For example, if in the 
shell we turn profiling on, for all subsequent requests the profiling stats 
will be pretty printed, or optionally written to a file.]


  was:
Add ability to get HBase metrics back from an individual request. Apps can use 
this to track fine-grained metrics (such as server-side latency, block cache 
access/hit count; sync latency; append latency; etc.) on a per-API call basis. 
Also, enhance HBase shell to also support this feature. [For example, if in the 
shell we turn profiling on, for all subsequent requests the profiling stats 
will be pretty printed, or optionally written to a file.]



 per-request profiling
 -

 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Add ability to get HBase metrics back from an individual request. Apps can 
 use this to track fine-grained metrics (such as server-side latency, block 
 cache access/hit count; sync latency; append latency; etc.) on a per-API call 
 basis. Also, enhance HBase shell to support this feature. [For example, if in 
 the shell we turn profiling on, for all subsequent requests the profiling 
 stats will be pretty printed, or optionally written to a file.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6216) per-request tagging


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

Kannan Muthukkaruppan updated HBASE-6216:
-

Description: 
Allow applications to tag individual RPC requests so that metrics exposed by 
HBase can automatically be collected/aggregated by those tags. This'll be 
useful for problem diagnosis across various applications-- as it will allow us 
to correlate HBase metrics (such as data block misses) back to application 
level tags.

For example, 

* in some multi-tenancy type use case where many different applications are 
served out of a single Table or CF, it'll be useful to know the break down of 
metrics (such as bytes read, data block misses, get/put RPC calls, etc.) by 
application name (tag).

* even in a single app environment, the app may want to tag different API calls 
with different tags even if those calls are to the same CF.

  was:
Allow applications to tag individual RPC requests so that metrics exposed by 
HBase can automatically be collected/aggregated by those tags. This'll be 
useful for problem diagnosis across various applications-- as it will allow us 
to correlate HBase metrics (such as data block misses) back to application 
level tags.

For example, in some multi-tenancy type use case where many different 
applications are served out of a single Table or CF, it'll be useful to know 
the break down of metrics (such as bytes read, data block misses, get/put RPC 
calls, etc.) by application name (tag).


 per-request tagging
 ---

 Key: HBASE-6216
 URL: https://issues.apache.org/jira/browse/HBASE-6216
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Allow applications to tag individual RPC requests so that metrics exposed by 
 HBase can automatically be collected/aggregated by those tags. This'll be 
 useful for problem diagnosis across various applications-- as it will allow 
 us to correlate HBase metrics (such as data block misses) back to application 
 level tags.
 For example, 
 * in some multi-tenancy type use case where many different applications are 
 served out of a single Table or CF, it'll be useful to know the break down of 
 metrics (such as bytes read, data block misses, get/put RPC calls, etc.) by 
 application name (tag).
 * even in a single app environment, the app may want to tag different API 
 calls with different tags even if those calls are to the same CF.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6215) per-request profiling

2012-06-15 Thread Todd Lipcon (JIRA)


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

Todd Lipcon commented on HBASE-6215:


Cool. Our focus is more on (Dapper-like) tracing and a little less on metrics, 
but the two are clearly related.

 per-request profiling
 -

 Key: HBASE-6215
 URL: https://issues.apache.org/jira/browse/HBASE-6215
 Project: HBase
  Issue Type: New Feature
Reporter: Kannan Muthukkaruppan
Assignee: Aurick Qiao

 Add ability to get HBase metrics back from an individual request. Apps can 
 use this to track fine-grained metrics (such as server-side latency, block 
 cache access/hit count; sync latency; append latency; etc.) on a per-API call 
 basis. Also, enhance HBase shell to support this feature. [For example, if in 
 the shell we turn profiling on, for all subsequent requests the profiling 
 stats will be pretty printed, or optionally written to a file.]

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6207) Add jitter to client retry timer


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

Elliott Clark updated HBASE-6207:
-

Attachment: HBASE-6207-0.patch

[~nspiegelberg]
The client already has a semi exponential back off so I just added a jitter 
that was up to 1% of the previously calculated value.

Also added a test.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6207-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6207) Add jitter to client retry timer


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

Elliott Clark updated HBASE-6207:
-

Status: Patch Available  (was: Open)

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6207-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6207) Add jitter to client retry timer


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

Andrew Purtell commented on HBASE-6207:
---

+1 on patch

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6207-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

Elliott Clark commented on HBASE-6217:
--

This should be great, however can you upload a patch for trunk (see 
http://wiki.apache.org/hadoop/Hbase/HowToCommit on how to create the .patch 
file) so that we can release jenkins on it ?

Additionally I don't think that you need a null check before adding to 
cummulativeMetric.  The most used case will be that metric is not null so 
optimizing for that seems reasonable.

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
 Attachments: StoreScanner.java


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6207) Add jitter to client retry timer

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

Hadoop QA commented on HBASE-6207:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12532252/HBASE-6207-0.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 2 new or modified tests.

+1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.coprocessor.TestMasterObserver

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/2171//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2171//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2171//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/2171//console

This message is automatically generated.

Add jitter to client retry timer

Key: HBASE-6207
URL: https://issues.apache.org/jira/browse/HBASE-6207
Project: HBase
Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
Attachments: HBASE-6207-0.patch

[jira] [Updated] (HBASE-6211) Latencies not in jmx


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

Elliott Clark updated HBASE-6211:
-

Attachment: HBASE-6211-0.patch

Added the first pass at this.  I really should go back and make the strings 
constants defined in one place.

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6211) Latencies not in jmx


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

Elliott Clark updated HBASE-6211:
-

Status: Patch Available  (was: Open)

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6207) Add jitter to client retry timer


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

Elliott Clark commented on HBASE-6207:
--

I ran the test that failed locally three times and I always got a pass.  Seems 
like it's un-related.

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6207-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6220) PersistentMetricsTimeVaryingRate gets used for non-time-based metrics

2012-06-15 Thread David S. Wang (JIRA)

David S. Wang created HBASE-6220:


 Summary: PersistentMetricsTimeVaryingRate gets used for 
non-time-based metrics
 Key: HBASE-6220
 URL: https://issues.apache.org/jira/browse/HBASE-6220
 Project: HBase
  Issue Type: Bug
  Components: metrics
Affects Versions: 0.96.0
Reporter: David S. Wang
Priority: Minor


PersistentMetricsTimeVaryingRate gets used for metrics that are not time-based, 
leading to confusing names such as avg_time for compaction size, etc.  You 
hav to read the code in order to understand that this is actually referring to 
bytes, not seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (HBASE-6221) Backport HBASE-6135 to 0.94 branch

Andrew Purtell created HBASE-6221:
-

 Summary: Backport HBASE-6135 to 0.94 branch
 Key: HBASE-6221
 URL: https://issues.apache.org/jira/browse/HBASE-6221
 Project: HBase
  Issue Type: Bug
Reporter: Andrew Purtell
Priority: Minor


As discussed in the HBase BoF today, a patch backporting HBASE-6135 UI 
improvements to 0.94 may be interesting even if not actually committed to that 
branch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6211) Latencies not in jmx


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

Elliott Clark updated HBASE-6211:
-

Attachment: HBASE-6211-1.patch

Added constants.

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6221) Backport HBASE-6135 to 0.94 branch


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

Andrew Purtell updated HBASE-6221:
--

Attachment: HBASE-6221.patch

 Backport HBASE-6135 to 0.94 branch
 --

 Key: HBASE-6221
 URL: https://issues.apache.org/jira/browse/HBASE-6221
 Project: HBase
  Issue Type: Bug
Reporter: Andrew Purtell
Priority: Minor
 Attachments: HBASE-6221.patch


 As discussed in the HBase BoF today, a patch backporting HBASE-6135 UI 
 improvements to 0.94 may be interesting even if not actually committed to 
 that branch.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6209) ACL Corrections for AccessControllerProtocol apis


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

Andrew Purtell commented on HBASE-6209:
---

bq. Append operation also has no authorization check.

Append was added after initial drop, so didn't get coverage. Agree WRITE is 
needed.

Looks good to me. 

 ACL Corrections for AccessControllerProtocol apis
 -

 Key: HBASE-6209
 URL: https://issues.apache.org/jira/browse/HBASE-6209
 Project: HBase
  Issue Type: Sub-task
  Components: security
Affects Versions: 0.94.0, 0.96.0, 0.94.1
Reporter: Laxman
Assignee: Laxman
  Labels: acl, security
 Fix For: 0.96.0, 0.94.1


 APIs provided in AccessController are authorized against global-admin 
 permissions. Instead we need to check for table-admin level permissions.
 Edit: Append operation also has no authorization check. We can update it 
 together.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6151) Master can die if RegionServer throws ServerNotRunningYet

2012-06-15 Thread Gregory Chanan (JIRA)


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

Gregory Chanan updated HBASE-6151:
--

Affects Version/s: (was: 0.94.1)
   (was: 0.96.0)
   (was: 0.92.2)

I may have been wrong about this affecting 0.92+.  It looks like HBASE-4455 
fixed this in 0.92.  I'll look at backporting.

 Master can die if RegionServer throws ServerNotRunningYet
 -

 Key: HBASE-6151
 URL: https://issues.apache.org/jira/browse/HBASE-6151
 Project: HBase
  Issue Type: Bug
  Components: ipc
Affects Versions: 0.90.7
Reporter: Gregory Chanan
Assignee: Gregory Chanan

 See, for example:
 {noformat}
 2012-05-23 16:49:22,745 FATAL org.apache.hadoop.hbase.master.HMaster: 
 Unhandled exception. Starting shutdown.
 org.apache.hadoop.hbase.ipc.ServerNotRunningException: 
 org.apache.hadoop.hbase.ipc.ServerNotRunningException: Server is not running 
 yet
   at 
 org.apache.hadoop.hbase.ipc.HBaseServer$Handler.run(HBaseServer.java:1038)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   at 
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   at 
 org.apache.hadoop.hbase.RemoteExceptionHandler.decodeRemoteException(RemoteExceptionHandler.java:96)
   at 
 org.apache.hadoop.hbase.client.HConnectionManager$HConnectionImplementation.getHRegionConnection(HConnectionManager.java:1240)
   at 
 org.apache.hadoop.hbase.catalog.CatalogTracker.getCachedConnection(CatalogTracker.java:444)
   at 
 org.apache.hadoop.hbase.catalog.CatalogTracker.getMetaServerConnection(CatalogTracker.java:343)
   at 
 org.apache.hadoop.hbase.catalog.CatalogTracker.verifyMetaRegionLocation(CatalogTracker.java:540)
   at 
 org.apache.hadoop.hbase.master.HMaster.assignRootAndMeta(HMaster.java:474)
   at 
 org.apache.hadoop.hbase.master.HMaster.finishInitialization(HMaster.java:412)
 {noformat}
 The HRegionServer calls HBaseServer:
 {code}
   public void start() {
 startThreads();
 openServer();
   }
 {code}
 but the server can start accepting RPCs once the threads have been started, 
 but if they do, they throw ServerNotRunningException until openServer runs.  
 We should probably
 1) Catch the remote exception and retry on the master
 2) Look into whether the start() behavior of HBaseServer makes any sense.  
 Why would you start accepting RPCs only to throw back 
 ServerNotRunningException?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6135) Style the Web UI to use Twitter's Bootstrap.


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

Hudson commented on HBASE-6135:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #55 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/55/])
HBASE-6135 Style the Web UI to use Twitter's Bootstrap, addendum (Elliot 
Clark)

Submitted by:   Elliot Clark
Reviewed by:Ted Yu (Revision 1350731)

 Result = FAILURE
tedyu : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/jamon/org/apache/hadoop/hbase/tmpl/regionserver/RegionListTmpl.jamon


 Style the Web UI to use Twitter's Bootstrap.
 

 Key: HBASE-6135
 URL: https://issues.apache.org/jira/browse/HBASE-6135
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Fix For: 0.96.0

 Attachments: HBASE-6135-0.patch, HBASE-6135-1.patch, 
 HBASE-6135-2.patch, HBASE-6135-3.patch, HBASE-6135-4.patch, 
 HBASE-6135-5.patch, HBASE-6135-ADD-0.patch, master-redesign.png, 
 redesign-master-r1.png, redesign-rs-r1.png


 Our web ui has lagged a little bit behind.  While it's not a huge deal, it is 
 one of the first things that new people see.  As such styling it a little bit 
 better would put a good foot forward.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5564) Bulkload is discarding duplicate records


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

Hudson commented on HBASE-5564:
---

Integrated in HBase-TRUNK-on-Hadoop-2.0.0 #55 (See 
[https://builds.apache.org/job/HBase-TRUNK-on-Hadoop-2.0.0/55/])
HBASE-5564 Bulkload is discarding duplicate records

Submitted by:Laxman 
Reviewed by:iStack, Ted, Ram (Revision 1350691)

 Result = FAILURE
ramkrishna : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/ImportTsv.java
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/mapreduce/TsvImporterMapper.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/mapreduce/TestImportTsv.java


 Bulkload is discarding duplicate records
 

 Key: HBASE-5564
 URL: https://issues.apache.org/jira/browse/HBASE-5564
 Project: HBase
  Issue Type: Bug
  Components: mapreduce
Affects Versions: 0.96.0
 Environment: HBase 0.92
Reporter: Laxman
Assignee: Laxman
  Labels: bulkloader
 Fix For: 0.96.0

 Attachments: 5564.lint, 5564v5.txt, HBASE-5564.patch, 
 HBASE-5564_1.patch, HBASE-5564_trunk.1.patch, HBASE-5564_trunk.1.patch, 
 HBASE-5564_trunk.2.patch, HBASE-5564_trunk.3.patch, 
 HBASE-5564_trunk.4_final.patch, HBASE-5564_trunk.patch


 Duplicate records are getting discarded when duplicate records exists in same 
 input file and more specifically if they exists in same split.
 Duplicate records are considered if the records are from diffrent different 
 splits.
 Version under test: HBase 0.92

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6211) Latencies not in jmx

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

Hadoop QA commented on HBASE-6211:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12532273/HBASE-6211-1.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 tests included. 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.

+1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

+1 core tests. The patch passed unit tests in .

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/2173//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2173//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2173//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/2173//console

This message is automatically generated.

Latencies not in jmx

Key: HBASE-6211
URL: https://issues.apache.org/jira/browse/HBASE-6211
Project: HBase
Issue Type: Bug
Environment: RegionServerMetrics pushes latency histograms to hadoop
metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch

[jira] [Commented] (HBASE-6211) Latencies not in jmx

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

Hadoop QA commented on HBASE-6211:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12532267/HBASE-6211-0.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

+1 hadoop2.0. The patch compiles against the hadoop 2.0 profile.

+1 javadoc. The javadoc tool did not generate any warning messages.

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

-1 findbugs. The patch appears to introduce 7 new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

-1 core tests. The patch failed these unit tests:
org.apache.hadoop.hbase.replication.TestReplication

Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/2172//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2172//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/2172//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/2172//console

This message is automatically generated.

Latencies not in jmx

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Labels: patch  (was: )
Status: Patch Available  (was: Open)

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Status: Open  (was: Patch Available)

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Attachment: (was: StoreScanner.java)

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Attachment: jira-6217.patch

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

M. Chen updated HBASE-6217:
---

Release Note: Reduce overhead of size metric maintained in 
StoreScanner.next().
  Status: Patch Available  (was: Open)

Reduce overhead of size metric maintained in StoreScanner.next() by 
accumulating the increments and applying them all at once at the end.

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric

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

Hadoop QA commented on HBASE-6217:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12532287/jira-6217.patch
against trunk revision .

+1 @author. The patch does not contain any @author tags.

-1 patch. The patch command could not apply the patch.

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

This message is automatically generated.

reduce overhead of maintaing get/next size metric
-

Key: HBASE-6217
URL: https://issues.apache.org/jira/browse/HBASE-6217
Project: HBase
Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
Labels: patch
Attachments: jira-6217.patch

[Forked off this specific issue as a separate JIRA from HBASE-6066].
Reduce overhead of size metric maintained in StoreScanner.next().
{code}
if (metric != null) {
HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
}
results.add(copyKv);
{code}
A single call to next() might fetch a lot of KVs. We can first add up the
size of those KVs in a local variable and then in a finally clause increment
the metric one shot, rather than updating AtomicLongs for each KV.

[jira] [Updated] (HBASE-5838) Add an LZ4 compression option to HFile


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

Andrew Purtell updated HBASE-5838:
--

   Resolution: Fixed
Fix Version/s: 0.94.1
   0.96.0
   Status: Resolved  (was: Patch Available)

Committed to trunk and 0.94 branch. Additional case to TestHFile passes 
locally. 

 Add an LZ4 compression option to HFile
 --

 Key: HBASE-5838
 URL: https://issues.apache.org/jira/browse/HBASE-5838
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.2, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.96.0, 0.94.1

 Attachments: 5838.patch


 HADOOP-7657 adds support for LZ4 compression to Hadoop core. As with Snappy, 
 we should add reflection based support for this alternative to 
 HFile.Compression. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6207) Add jitter to client retry timer


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

Zhihong Ted Yu commented on HBASE-6207:
---

{code}
+  private static final Random RANDOM = new Random();
{code}
Can you initialize the above with a seed (such as current time) ?

 Add jitter to client retry timer
 

 Key: HBASE-6207
 URL: https://issues.apache.org/jira/browse/HBASE-6207
 Project: HBase
  Issue Type: Improvement
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6207-0.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric


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

Zhihong Ted Yu commented on HBASE-6217:
---

@M:
The source file is now under hbase-server/

Please resubmit patch.

 reduce overhead of maintaing get/next size metric
 -

 Key: HBASE-6217
 URL: https://issues.apache.org/jira/browse/HBASE-6217
 Project: HBase
  Issue Type: Improvement
Reporter: Kannan Muthukkaruppan
Assignee: M. Chen
  Labels: patch
 Attachments: jira-6217.patch


 [Forked off this specific issue as a separate JIRA from HBASE-6066].
 Reduce overhead of size metric maintained in StoreScanner.next().
 {code}
 if (metric != null) {
  HRegion.incrNumericMetric(this.metricNamePrefix + metric,
copyKv.getLength());
   }
   results.add(copyKv);
 {code}
 A single call to next() might fetch a lot of KVs. We can first add up the 
 size of those KVs in a local variable and then in a finally clause increment 
 the metric one shot, rather than updating AtomicLongs for each KV.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-6211) Latencies not in jmx

2012-06-15 Thread Otis Gospodnetic (JIRA)


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

Otis Gospodnetic updated HBASE-6211:


Component/s: monitoring
 metrics

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
  Components: metrics, monitoring
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (HBASE-5601) Add per-column-family data block cache hit ratios

2012-06-15 Thread Otis Gospodnetic (JIRA)


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

Otis Gospodnetic updated HBASE-5601:


Component/s: monitoring
 metrics

 Add per-column-family data block cache hit ratios
 -

 Key: HBASE-5601
 URL: https://issues.apache.org/jira/browse/HBASE-5601
 Project: HBase
  Issue Type: Improvement
  Components: metrics, monitoring
Reporter: Mikhail Bautin
Assignee: Enis Soztutar

 In addition to the overall block cache hit ratio it would be extremely useful 
 to have per-column-family data block cache hit ratio metrics.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6211) Latencies not in jmx


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

Zhihong Ted Yu commented on HBASE-6211:
---

Patch looks good.

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
  Components: metrics, monitoring
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5838) Add an LZ4 compression option to HFile


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

Hudson commented on HBASE-5838:
---

Integrated in HBase-TRUNK #3033 (See 
[https://builds.apache.org/job/HBase-TRUNK/3033/])
HBASE-5838. Add an LZ4 compression option to HFile (Revision 1350844)

 Result = SUCCESS
apurtell : 
Files : 
* 
/hbase/trunk/hbase-server/src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
* 
/hbase/trunk/hbase-server/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFile.java


 Add an LZ4 compression option to HFile
 --

 Key: HBASE-5838
 URL: https://issues.apache.org/jira/browse/HBASE-5838
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.2, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.96.0, 0.94.1

 Attachments: 5838.patch


 HADOOP-7657 adds support for LZ4 compression to Hadoop core. As with Snappy, 
 we should add reflection based support for this alternative to 
 HFile.Compression. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6211) Latencies not in jmx

2012-06-15 Thread stack (JIRA)


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

stack commented on HBASE-6211:
--

+1 on patch.  Elliott, can you prove they show up in jmx?  Then we'll commit.

 Latencies not in jmx
 

 Key: HBASE-6211
 URL: https://issues.apache.org/jira/browse/HBASE-6211
 Project: HBase
  Issue Type: Bug
  Components: metrics, monitoring
 Environment: RegionServerMetrics pushes latency histograms to hadoop 
 metrics, but they are not getting into jmx.
Reporter: Elliott Clark
Assignee: Elliott Clark
 Attachments: HBASE-6211-0.patch, HBASE-6211-1.patch




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-5838) Add an LZ4 compression option to HFile


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

Hudson commented on HBASE-5838:
---

Integrated in HBase-0.94 #258 (See 
[https://builds.apache.org/job/HBase-0.94/258/])
HBASE-5838. Add an LZ4 compression option to HFile (Revision 1350845)

 Result = FAILURE
apurtell : 
Files : 
* 
/hbase/branches/0.94/src/main/java/org/apache/hadoop/hbase/io/hfile/Compression.java
* 
/hbase/branches/0.94/src/test/java/org/apache/hadoop/hbase/io/hfile/TestHFile.java


 Add an LZ4 compression option to HFile
 --

 Key: HBASE-5838
 URL: https://issues.apache.org/jira/browse/HBASE-5838
 Project: HBase
  Issue Type: Improvement
Affects Versions: 0.92.2, 0.96.0, 0.94.1
Reporter: Andrew Purtell
Assignee: Andrew Purtell
Priority: Minor
 Fix For: 0.96.0, 0.94.1

 Attachments: 5838.patch


 HADOOP-7657 adds support for LZ4 compression to Hadoop core. As with Snappy, 
 we should add reflection based support for this alternative to 
 HFile.Compression. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-6217) reduce overhead of maintaing get/next size metric