[
https://issues.apache.org/jira/browse/PHOENIX-1261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15057116#comment-15057116
]
Samarth Jain edited comment on PHOENIX-1261 at 12/15/15 1:15 AM:
-----------------------------------------------------------------
Work in progress patch. I was able to manually run UPDATE STATS call which
returned immediately with the scanners chugging along on the region servers.
This patch doesn't have the grammar changes in yet i.e. by default we are
running UPDATE STATS asynchronously.
There are a couple of open questions though:
1) Should phoenix be using it's own thread pool on the region server side? Or
is there a way to get hold of an existing thread pool running on region
servers?
Currently I created a size 2 thread pool (will make it configurable) which is
going be shared by all update stats calls running on a region server.
2) Currently I am making sure that the wrapped scanner returned by
doPostScannerOpen doesn't close the actual internal region scanner. We manage
the closing of the internal scanners ourselves. Are there any untoward
ramifications of doing that?
PS - will remove the System.out calls in the actual patch. Parking the wip
patch for preliminary feedback.
was (Author: samarthjain):
Work in progress patch. I was able to manually run UPDATE STATS call which
returned immediately with the scanners chugging along on the region servers.
This patch doesn't have the grammar changes in yet i.e. by default we are
running UPDATE STATS asynchronously.
There are a couple of open questions though:
1) Should phoenix be using it's own thread pool on the region server side? Or
is there a way to get hold of an existing thread pool running on region
servers?
Currently I created a size 2 thread pool (will make it configurable) which is
going be shared by all update stats calls running on a region server.
2) Currently I am making sure that the wrapped scanner returned by
doPostScannerOpen doesn't close the actual internal region scanner. We manage
the closing of the internal scanners ourselves. Are there any untoward
ramifications of doing that?
> 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)
