Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Thu, 24 Jul 2014 20:31:38 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12729558.1406233868421.39919.1406233898949@arcas>
In-Reply-To: <JIRA.12729558.1406233868421@arcas>
References: <JIRA.12729558.1406233868421@arcas>
Subject: [jira] [Created] (HBASE-11586) HFile's HDFS op latency sampling
 code is not used
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Andrew Purtell created HBASE-11586:
--------------------------------------

             Summary: 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


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)