phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-1261) Update stats table asynchronously
Date Tue, 15 Dec 2015 02:08:46 GMT


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:
>             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

View raw message