[
https://issues.apache.org/jira/browse/PHOENIX-2859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15259125#comment-15259125
]
Samarth Jain commented on PHOENIX-2859:
---------------------------------------
[~ndimiduk] - could/should this be tied with renewing scanner leases? Does
renewing a scanner lease today also reset the time tracker for RPC (a cursory
look at the HBase code doesn't say so) ? We already have a framework in Phoenix
to renew scanner leases. May be we can utilize it for RPC heartbeats too.
> 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)
