phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-1261) Update stats table asynchronously
Date Fri, 18 Dec 2015 21:03:46 GMT

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

James Taylor commented on PHOENIX-1261:
---------------------------------------

Thanks, [~samarthjain]. I think we should continue to do all the calculation of the new/deleted
guideposts for splits/compaction in line, but only do the stats.commitStats(mutations) asynchronously
- that's the code that potentially does an UPSERT across the wire to the Phoenix stats table.
Also, do you need to have COMMIT_STATS_ASYNC config property? If not, I'd remove it and just
always do the commitStats asynchronously, even in tests.

> 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, PHOENIX-1261_master.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)

Mime
View raw message