Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EB7BBDABA for ; Thu, 12 Jul 2012 19:31:35 +0000 (UTC) Received: (qmail 46614 invoked by uid 500); 12 Jul 2012 19:31:35 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 46546 invoked by uid 500); 12 Jul 2012 19:31:35 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 46394 invoked by uid 99); 12 Jul 2012 19:31:35 -0000 Received: from issues-vm.apache.org (HELO issues-vm) (140.211.11.160) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jul 2012 19:31:35 +0000 Received: from isssues-vm.apache.org (localhost [127.0.0.1]) by issues-vm (Postfix) with ESMTP id 0B6BD141887 for ; Thu, 12 Jul 2012 19:31:35 +0000 (UTC) Date: Thu, 12 Jul 2012 19:31:35 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: issues@hbase.apache.org Message-ID: <123169580.43534.1342121495049.JavaMail.jiratomcat@issues-vm> In-Reply-To: <788582677.39750.1342059575344.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Comment Edited] (HBASE-6377) HBASE-5533 metrics miss all operations submitted via MultiAction MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-6377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13413104#comment-13413104 ] Lars Hofhansl edited comment on HBASE-6377 at 7/12/12 7:29 PM: --------------------------------------------------------------- Looks good to me. Reasoning makes sense. We can report per op latency just by dividing the batch latency by the batch size (still no need to deconstruct per individual op). Not sure if that more useful or less. Does this need more discussion? If so, maybe the best course of action is to revert HBASE-5533 now and regroup. was (Author: lhofhansl): Looks good to me. Reasoning makes sense. We can report per of latency just by dividing the batch latency by the batch size (still no need to deconstruct per individual op). Not sure if that more useful or less. Does this need more discussion? If so, maybe the best course of action is to revert HBASE-5533 now and regroup. > HBASE-5533 metrics miss all operations submitted via MultiAction > ---------------------------------------------------------------- > > Key: HBASE-6377 > URL: https://issues.apache.org/jira/browse/HBASE-6377 > Project: HBase > Issue Type: Bug > Components: metrics, regionserver > Affects Versions: 0.96.0, 0.94.1 > Reporter: Andrew Purtell > Assignee: Andrew Purtell > Fix For: 0.94.2 > > Attachments: 6377-trunk-simple.patch > > > A client application (LoadTestTool) calls put() on HTables. Internally to the HBase client those puts are batched into MultiActions. The total number of put operations shown in the RegionServer's put metrics histogram never increases from 0 even though millions of such operations are made. Needless to say the latency for those operations are not measured either. The value of HBASE-5533 metrics are suspect given the client will batch put and delete ops like this. > I had a fix in progress but HBASE-6284 messed it up. Before, MultiAction processing in HRegionServer would distingush between puts and deletes and dispatch them separately. It was easy to account for the time for them. Now both puts and deletes are submitted in batch together as mutations. -- 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