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 2EDE6200C15 for ; Wed, 8 Feb 2017 19:40:03 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 2D762160B5A; Wed, 8 Feb 2017 18:40:03 +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 744A7160B49 for ; Wed, 8 Feb 2017 19:40:02 +0100 (CET) Received: (qmail 13755 invoked by uid 500); 8 Feb 2017 18:40:01 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 13744 invoked by uid 99); 8 Feb 2017 18:40:01 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Feb 2017 18:40:01 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 1B947C24E7 for ; Wed, 8 Feb 2017 18:40:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id K5vUEEPMZfD7 for ; Wed, 8 Feb 2017 18:40:00 +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 406D55F589 for ; Wed, 8 Feb 2017 18:40:00 +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 5C0C1E04DB for ; Wed, 8 Feb 2017 18:39:42 +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 C04542528E for ; Wed, 8 Feb 2017 18:39:41 +0000 (UTC) Date: Wed, 8 Feb 2017 18:39:41 +0000 (UTC) From: "Enis Soztutar (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-3360) Secondary index configuration is wrong MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 08 Feb 2017 18:40:03 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858369#comment-15858369 ] Enis Soztutar commented on PHOENIX-3360: ---------------------------------------- bq. When ever one of the phoenix table region opened in the RS we are setting the property with ServerRpcControllerFactory It is the Indexer setting the configuration. Even if there are no tables with index, do we still instantiate the Indexer? bq. With William Yang's patch the short-circuit write optimization will not work because the connection created is not a coprocessor connection. That is a good point. We need the short circuit'ing logic, otherwise it is another cause for deadlocking the threads. > Secondary index configuration is wrong > -------------------------------------- > > Key: PHOENIX-3360 > URL: https://issues.apache.org/jira/browse/PHOENIX-3360 > Project: Phoenix > Issue Type: Bug > Reporter: Enis Soztutar > Assignee: Rajeshbabu Chintaguntla > Priority: Critical > Fix For: 4.10.0 > > Attachments: PHOENIX-3360.patch, PHOENIX-3360-v2.PATCH > > > IndexRpcScheduler allocates some handler threads and uses a higher priority for RPCs. The corresponding IndexRpcController is not used by default as it is, but used through ServerRpcControllerFactory that we configure from Ambari by default which sets the priority of the outgoing RPCs to either metadata priority, or the index priority. > However, after reading code of IndexRpcController / ServerRpcController it seems that the IndexRPCController DOES NOT look at whether the outgoing RPC is for an Index table or not. It just sets ALL rpc priorities to be the index priority. The intention seems to be the case that ONLY on servers, we configure ServerRpcControllerFactory, and with clients we NEVER configure ServerRpcControllerFactory, but instead use ClientRpcControllerFactory. We configure ServerRpcControllerFactory from Ambari, which in affect makes it so that ALL rpcs from Phoenix are only handled by the index handlers by default. It means all deadlock cases are still there. > The documentation in https://phoenix.apache.org/secondary_indexing.html is also wrong in this sense. It does not talk about server side / client side. Plus this way of configuring different values is not how HBase configuration is deployed. We cannot have the configuration show the ServerRpcControllerFactory even only for server nodes, because the clients running on those nodes will also see the wrong values. -- This message was sent by Atlassian JIRA (v6.3.15#6346)