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 8D940200498 for ; Tue, 29 Aug 2017 20:01:11 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8C2611673D5; Tue, 29 Aug 2017 18:01:11 +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 DADED1673CE for ; Tue, 29 Aug 2017 20:01:10 +0200 (CEST) Received: (qmail 6641 invoked by uid 500); 29 Aug 2017 18:01:10 -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 6627 invoked by uid 99); 29 Aug 2017 18:01:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Aug 2017 18:01:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 414521A4E60 for ; Tue, 29 Aug 2017 18:01:09 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-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-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id AFncuGCJX42L for ; Tue, 29 Aug 2017 18:01:08 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id A12EC61032 for ; Tue, 29 Aug 2017 18:01:07 +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 44284E0EB5 for ; Tue, 29 Aug 2017 18:01:06 +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 071E12416F for ; Tue, 29 Aug 2017 18:01:04 +0000 (UTC) Date: Tue, 29 Aug 2017 18:01:04 +0000 (UTC) From: "Vincent Poon (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-3815) Only disable indexes on which write failures occurred MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 29 Aug 2017 18:01:11 -0000 [ https://issues.apache.org/jira/browse/PHOENIX-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16145787#comment-16145787 ] Vincent Poon commented on PHOENIX-3815: --------------------------------------- [~jamestaylor] now that we've lowered the index write timeout (PHOENIX-3948), I suppose TrackingWriter isn't as bad. However, there are still some corner cases where it will be noticeably slower than ParallelWriter. Imagine all threads in the writer pool (default of 10) are in use and there is heavy write traffic - the writes will then be executed serially as threads become available, and you'd have to wait for each to fail in the worst case where all indexes are failing. But I think these might be relatively rare cases. Also if the failure policy is to disable the index, then it doesn't matter too much. Either way, we should at a minimum extract out the common code in the classes if we're not going to remove one - they pretty much do the same thing but use a different TaskRunner. If the failure policy is to leave the index enabled, then you might care about failing fast, as you could face repeated failures if something is wrong with the index RS. We could also have a rate counter for # of failures in a given time window. If # of failures exceeds that, we fail fast like ParallelWriter. Otherwise, use TrackingWriter logic in the normal happy case. But again, only matters if you plan to leave the index enabled. > Only disable indexes on which write failures occurred > ----------------------------------------------------- > > Key: PHOENIX-3815 > URL: https://issues.apache.org/jira/browse/PHOENIX-3815 > Project: Phoenix > Issue Type: Bug > Reporter: James Taylor > Assignee: Vincent Poon > Fix For: 4.12.0 > > Attachments: PHOENIX-3815.v1.patch > > > We currently disable all indexes if any of them fail to be written to. We really only should disable the one in which the write failed. -- This message was sent by Atlassian JIRA (v6.4.14#64029)