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 4EA49200B96 for ; Thu, 22 Sep 2016 07:07:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 4D1D7160ADE; Thu, 22 Sep 2016 05:07:22 +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 91795160ADB for ; Thu, 22 Sep 2016 07:07:21 +0200 (CEST) Received: (qmail 88372 invoked by uid 500); 22 Sep 2016 05:07:20 -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 88355 invoked by uid 99); 22 Sep 2016 05:07:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Sep 2016 05:07:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 766922C2A62 for ; Thu, 22 Sep 2016 05:07:20 +0000 (UTC) Date: Thu, 22 Sep 2016 05:07:20 +0000 (UTC) From: "Sean Busbey (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-16676) All RPC requests serviced by PriorityRpcServer in some deploys after HBASE-13375 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 22 Sep 2016 05:07:22 -0000 [ https://issues.apache.org/jira/browse/HBASE-16676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15512170#comment-15512170 ] Sean Busbey commented on HBASE-16676: ------------------------------------- no worries [~ashish singhi]. do you think the impact doesn't warrant the change in behavior? > All RPC requests serviced by PriorityRpcServer in some deploys after HBASE-13375 > -------------------------------------------------------------------------------- > > Key: HBASE-16676 > URL: https://issues.apache.org/jira/browse/HBASE-16676 > Project: HBase > Issue Type: Bug > Affects Versions: 1.2.0, 1.2.1, 1.2.2, 1.2.3 > Reporter: Andrew Purtell > Assignee: Andrew Purtell > Fix For: 1.2.4 > > Attachments: HBASE-16676-branch-1.2.patch > > > I have been trying to track down why 1.2.x won't sometimes pass a 1 billion row ITBLL run while 0.98.22 and 1.1.6 will always, and a defeat of RPC prioritization could explain it. We get stuck during the loading phase and the loader job eventually fails. > All testing is done in an insecure environment under the same UNIX user (clusterdock) so effectively all ops are issued by the superuser. > Doing unrelated work - or so I thought! - I was looking at object allocations by YCSB workload by thread and when looking at the RegionServer RPC threads noticed that for 0.98.22 and 1.1.6, as expected, the vast majority of allocations are from threads named "B.defaultRpcServer.handler*". In 1.2.0 and up, instead the vast majority are from threads named "PriorityRpcServer.handler*" with very little from threads named "B.defaultRpcServer.handler*". A git bisect to find the change that causes this leads to HBASE-13375, and so of course this makes sense out of what I am seeing, but is this really what we want? What about production environments (insecure and degenerate secure) where all ops are effectively issued by the superuser? We run one of these at Salesforce. -- This message was sent by Atlassian JIRA (v6.3.4#6332)