Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id E70AB200CD9 for ; Thu, 3 Aug 2017 18:59:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id E598C16BEAE; Thu, 3 Aug 2017 16:59:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 3FD1B16BEAF for ; Thu, 3 Aug 2017 18:59:05 +0200 (CEST) Received: (qmail 2448 invoked by uid 500); 3 Aug 2017 16:59:04 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 2437 invoked by uid 99); 3 Aug 2017 16:59:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 03 Aug 2017 16:59:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id E5F9D1A0847 for ; Thu, 3 Aug 2017 16:59:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id p6uBxbHNgJ1q for ; Thu, 3 Aug 2017 16:59:03 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 2ED2F60D9B for ; Thu, 3 Aug 2017 16:59:02 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 7A05FE0E37 for ; Thu, 3 Aug 2017 16:59:01 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id B079B24660 for ; Thu, 3 Aug 2017 16:59:00 +0000 (UTC) Date: Thu, 3 Aug 2017 16:59:00 +0000 (UTC) From: "Daryn Sharp (JIRA)" To: common-issues@hadoop.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HADOOP-14599) RPC queue time metrics omit timed out clients MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 03 Aug 2017 16:59:06 -0000 [ https://issues.apache.org/jira/browse/HADOOP-14599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16113082#comment-16113082 ] Daryn Sharp commented on HADOOP-14599: -------------------------------------- General implementation issues: # No need to change UGI. Revert them. # Don't change {{RpcProtobufRequest#getRequestHeader}} to convert IOE to an illegal arg. # In {{NamenodeWebHdfsMethods#doAsExternalCall}}, the changed indentation of methods like {{getHostInetAddress}} and {{getDeclaringClassProtocolName}} violate style guidelines. # {{WritableRpcEngine#call}} doesn't appear to need the finally clause anymore? # Is the change in {{Server}} to the deferred response handling is necessary? It's subtlety changing the behavior. # In the finally block that updates the metrics, please update _after_ clearing the call and closing the scope. If for some reason the metrics update blow up, the handler will be left in an inconsistent state. Most importantly: The queue time for skipped calls is recorded = great!; _but with a processing time of 0_ = bad. As the call queue becomes congested with timing out clients, the average processing time will plummet and artificially make performance appear great when it's not. The updates to queue time and processing time need to be independent. > RPC queue time metrics omit timed out clients > --------------------------------------------- > > Key: HADOOP-14599 > URL: https://issues.apache.org/jira/browse/HADOOP-14599 > Project: Hadoop Common > Issue Type: Bug > Components: metrics, rpc-server > Affects Versions: 2.7.0 > Reporter: Ashwin Ramesh > Assignee: Ashwin Ramesh > Attachments: HADOOP-14599.001.patch, HADOOP-14599-002.patch, HADOOP-14599-003.patch, HADOOP-14599-004.patch > > > RPC average queue time metrics will now update even if the client who made the call timed out while the call was in the call queue. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: common-issues-unsubscribe@hadoop.apache.org For additional commands, e-mail: common-issues-help@hadoop.apache.org