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 AB673200CF2 for ; Wed, 19 Jul 2017 07:58:04 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id A9CC9168305; Wed, 19 Jul 2017 05:58:04 +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 0163E168307 for ; Wed, 19 Jul 2017 07:58:03 +0200 (CEST) Received: (qmail 35807 invoked by uid 500); 19 Jul 2017 05:58:02 -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 35778 invoked by uid 99); 19 Jul 2017 05:58:02 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Jul 2017 05:58:02 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id DF1A2C0048 for ; Wed, 19 Jul 2017 05:58:01 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, 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 (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id tTZq9XNZUCty for ; Wed, 19 Jul 2017 05:58:01 +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 0E8C15F340 for ; Wed, 19 Jul 2017 05:58:01 +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 9A883E0D48 for ; Wed, 19 Jul 2017 05:58:00 +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 56D3621EA5 for ; Wed, 19 Jul 2017 05:58:00 +0000 (UTC) Date: Wed, 19 Jul 2017 05:58:00 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-4028) Provide option to not throw index write failure back to client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 19 Jul 2017 05:58:04 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-4028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16092629#comment-16092629 ] James Taylor commented on PHOENIX-4028: --------------------------------------- You should be able to get rid of the race condition by running with your failRebuildTask as true, and with disableIndexOnWriteFailure as false. Without the patch, I think it would clear the INDEX_DISABLE_TIMESTAMP, but with the patch it shouldn't. > Provide option to not throw index write failure back to client > -------------------------------------------------------------- > > Key: PHOENIX-4028 > URL: https://issues.apache.org/jira/browse/PHOENIX-4028 > Project: Phoenix > Issue Type: Improvement > Reporter: James Taylor > Assignee: James Taylor > Fix For: 4.12.0 > > Attachments: PHOENIX-4028_addendum1.patch, PHOENIX-4028.patch, PHOENIX-4028_v2.patch, PHOENIX-4028_v3.patch, PHOENIX-4028_v4.patch, PHOENIX-4028_v5_wip.patch, PHOENIX-4028_wip.patch > > > Much like our DISABLE_INDEX_ON_WRITE_FAILURE and REBUILD_INDEX_ON_WRITE_FAILURE table properties, we need a THROW_INDEX_WRITE_FAILURE boolean option that can be used to prevent the index write from being thrown back to the client. In this case, the index failure policy would still be executed (i.e. disabling the index on a write failure), but any retry logic for the client would be avoided. The index would be eventually consistent based on the background partial index rebuild thread. -- This message was sent by Atlassian JIRA (v6.4.14#64029)