[
https://issues.apache.org/jira/browse/PHOENIX-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261375#comment-15261375
]
James Taylor commented on PHOENIX-2859:
---------------------------------------
[~samarthjain] - I'd be surprised if your fix for PHOENIX-1428 doesn't deal
with this already (when the HBase version is high enough to take advantage of
it). You can do a quick test by ensuring the RPC timeout is low (a few seconds)
and doing a {{COUNT ( * )}} query on a big table.
> RPC Heartbeats for aggregation coprocessors
> -------------------------------------------
>
> Key: PHOENIX-2859
> URL: https://issues.apache.org/jira/browse/PHOENIX-2859
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Nick Dimiduk
>
> Phoenix supports a range of analytical functions, including {{count}},
> {{sum}}, {{min}}, {{max}}, &c. Many of these are heavily supported by
> aggregation coprocessors. When the Phoenix table contains any significant
> amount of data, these aggregation functions can take a while. Mostly these
> queries will be killed by phoenix query timeout or hbase rpc timeout. Both of
> these settings must be increased in order to support these aggregation
> queries at all. This is pretty annoying because there's two configs managing
> similar things.
> We could better support these kinds of queries if our coprocessors supported
> a heart-beat functionality, similar to what was added in for HBase scanners
> in HBASE-13090. This lets us leave HBase's RPC timeout as the default and let
> queries be managed by Phoenix's query timeout. That keeps the cluster snappy
> and responsive for usual workloads, but still supports basic aggregations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
