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 A5315200C81 for ; Fri, 12 May 2017 03:18:07 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A3DE9160BCA; Fri, 12 May 2017 01:18:07 +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 EA6C4160BC7 for ; Fri, 12 May 2017 03:18:06 +0200 (CEST) Received: (qmail 99452 invoked by uid 500); 12 May 2017 01:18:06 -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 99432 invoked by uid 99); 12 May 2017 01:18:05 -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; Fri, 12 May 2017 01:18:05 +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 71A2ECF017 for ; Fri, 12 May 2017 01:18:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-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 (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id Se6F1URHbBKr for ; Fri, 12 May 2017 01:18:05 +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 D28A75F398 for ; Fri, 12 May 2017 01:18:04 +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 5BD8BE02C7 for ; Fri, 12 May 2017 01:18:04 +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 186FC21DF5 for ; Fri, 12 May 2017 01:18:04 +0000 (UTC) Date: Fri, 12 May 2017 01:18:04 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-3811) Do not disable index on write failure by default MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 12 May 2017 01:18:07 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16007468#comment-16007468 ] James Taylor commented on PHOENIX-3811: --------------------------------------- Thanks for the review, [~tdsilva]. I've pushed to master and 4.x branches. I had to disable MutableIndexFailureIT for 4.x-HBase-1.1 and 4.x-HBase-0.98 branches as we were seeing test failures due to row lock issues. I've filed PHOENIX-3848 for follow up work. > Do not disable index on write failure by default > ------------------------------------------------ > > Key: PHOENIX-3811 > URL: https://issues.apache.org/jira/browse/PHOENIX-3811 > Project: Phoenix > Issue Type: Bug > Reporter: James Taylor > Assignee: James Taylor > Fix For: 4.11.0 > > Attachments: PHOENIX-3811_v1.patch, PHOENIX-3811_v2.patch, PHOENIX-3811_v3.patch, PHOENIX-3811-wip1.patch, PHOENIX-3811-wip2.patch, PHOENIX-3811-wip3.patch, PHOENIX-3811-wip4.patch, PHOENIX-3811-wip5.patch, PHOENIX-3811-wip7.patch > > > We should provide a way to configure the system so that the server takes no specific action when an index write fails. Since we always throw the write failure back to the client, the client can often deal with failures more easily than the server since they have the batch of mutations in memory. Often times, allowing access to an index that may be one batch behind the data table is better than disabling it given the negative performance that will occur while the index cannot be written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)