[
https://issues.apache.org/jira/browse/PHOENIX-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057180#comment-15057180
]
James Taylor commented on PHOENIX-1261:
---------------------------------------
Nice! This is a really good improvement already. One potential way we can avoid
a grammar change is to have a new boolean config parameter
{{phoenix.stats.collect.asynchronous}} which defaults to true but is set to
false in {{QueryServicesTestImpl}} for testing. Running it asynchronously is
really the way to go IMO, so I think this may be simpler/better.
I asked Lars about whether or not there's a common thread pool, but he said no.
I think it's fine to create one for this that's shared across the RS. We've got
our GlobalCache singleton that you could hang it off of - it's initialized with
access to a Configuration object off of RegionCoprocessorEnvironment, so you
could make the thread pool size configurable.
> 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)
