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

Andrew Purtell edited comment on HBASE-11586 at 7/25/14 12:12 AM:
------------------------------------------------------------------

Updated patch. I was looking this over for commit and noticed that although 
HFileReadWriteTest wants to use the op count and nanotime accumulators to bench 
operations, those counters are not updated anywhere. grepped over all modules 
to confirm. The patch is larger because it now removes HFileReadWriteTest. 
Change is a continuation of earlier acked work without surprises. Going to 
commit to 0.98+ in a little while unless objection.


was (Author: apurtell):
Updated patch. I was looking this over for commit and noticed that although 
HFileReadWriteTest wants to use the op count and nanotime accumulators to bench 
operations, those counters are not updated anywhere. grepped over all modules 
to confirm. Change is a continuation of earlier acked work without surprises. 
Going to commit to 0.98+ in a little while unless objection.

> HFile's HDFS op latency sampling code is not used
> -------------------------------------------------
>
>                 Key: HBASE-11586
>                 URL: https://issues.apache.org/jira/browse/HBASE-11586
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.4
>            Reporter: Andrew Purtell
>             Fix For: 0.99.0, 0.98.5, 2.0.0
>
>         Attachments: HBASE-11586.patch, HBASE-11586.patch
>
>
> HFileReaderV2 calls HFile#offerReadLatency and HFileWriterV2 calls 
> HFile#offerWriteLatency but the samples are never drained. There are no 
> callers of HFile#getReadLatenciesNanos, HFile#getWriteLatenciesNanos, and 
> related. The three ArrayBlockingQueues we are using as sample buffers in 
> HFile will fill quickly and are never drained. 
> There are also no callers of HFile#getReadTimeMs or HFile#getWriteTimeMs, and 
> related, so we are incrementing a set of AtomicLong counters that will never 
> be read nor reset.
> We are calling System.nanoTime in block read and write paths twice but not 
> utilizing the measurements.
> We should hook this code back up to metrics or remove it.
> We are also not using HFile#getChecksumFailuresCount anywhere but in some 
> unit test code.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to