Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jira@apache.org
Date: Thu, 28 Aug 2014 14:20:08 +0000 (UTC)
From: "Adam Fuchs (JIRA)" <jira@apache.org>
To: notifications@accumulo.apache.org
Message-ID: <JIRA.12737454.1409235592190.496.1409235608628@arcas>
In-Reply-To: <JIRA.12737454.1409235592190@arcas>
References: <JIRA.12737454.1409235592190@arcas>
Subject: [jira] [Created] (ACCUMULO-3088) StatsIterator readCounter could be
 more accurate
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Adam Fuchs created ACCUMULO-3088:
------------------------------------

             Summary: StatsIterator readCounter could be more accurate
                 Key: ACCUMULO-3088
                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3088
             Project: Accumulo
          Issue Type: Bug
            Reporter: Adam Fuchs
            Priority: Trivial


When testing seek performance I noticed that the read count displayed on Accumulo's monitor page registered zero entries read per second and a positive number of entries per second returned. This should not be possible. There is a fencepost error in the StatsIterator where seeks don't count as entries read.

Successful completion of this ticket should handle the cases where a seek returns no entries, as well as where next is never called on an iterator.

The cost of incrementing an AtomicLong is something like 10ns, which is at least an order of magnitude more than the desired overhead. The current way of batching updates to the read counter should be preserved for performance.


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