Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@phoenix.apache.org
Date: Tue, 15 Dec 2015 01:26:46 +0000 (UTC)
From: "Samarth Jain (JIRA)" <jira@apache.org>
To: dev@phoenix.incubator.apache.org
Message-ID: <JIRA.12742519.1411060215000.21344.1450142806727@Atlassian.JIRA>
In-Reply-To: <JIRA.12742519.1411060215000@Atlassian.JIRA>
References: <JIRA.12742519.1411060215000@Atlassian.JIRA>
 <JIRA.12742519.1411060215220@arcas>
Subject: [jira] [Commented] (PHOENIX-1261) Update stats table asynchronously
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Samarth Jain commented on PHOENIX-1261:
---------------------------------------

Also, UPDATE STATS async completed fine on a 200 million row table. I also tested in scenarios where the client initiating UPDATE STATS was still connected/disconnected. In both scenarios UPDATE STATS finished fine.

> Update stats table asynchronously
> ---------------------------------
>
>                 Key: PHOENIX-1261
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1261
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Samarth Jain
>             Fix For: 4.7.0
>
>         Attachments: 1261-wip.patch
>
>
> Instead of writing the the stats table directly in the thread performing major compaction, we should instead write to it asynchronously, perhaps using the same asynchronous mechanism used by tracing. Apparently HBase used to have a "custodian" table where they'd write as compaction and other background tasks were running, and this leads to bad things happening if the table being written to can't be reached.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)