Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 25 Apr 2017 04:28:04 +0000 (UTC)
From: "Lars Hofhansl (JIRA)" <jira@apache.org>
To: dev@phoenix.apache.org
Message-ID: <JIRA.13066554.1493085807000.40898.1493094484033@Atlassian.JIRA>
In-Reply-To: <JIRA.13066554.1493085807000@Atlassian.JIRA>
References: <JIRA.13066554.1493085807000@Atlassian.JIRA> <JIRA.13066554.1493085807566@jira-lw-us.apache.org>
Subject: [jira] [Commented] (PHOENIX-3811) Ignore index write failure and
 let client deal with failure
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Tue, 25 Apr 2017 04:28:09 -0000


    [ https://issues.apache.org/jira/browse/PHOENIX-3811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982342#comment-15982342 ] 

Lars Hofhansl commented on PHOENIX-3811:
----------------------------------------

I think this should be configurable per index or at least per table.
Many use cases may want this behavior, but I suspect there most do not want incorrect answers.

At least per table should not be hard with HBase's per table config overrides.

> Ignore index write failure and let client deal with failure
> -----------------------------------------------------------
>
>                 Key: PHOENIX-3811
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3811
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>
> 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)