You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kylin.apache.org by "Dayue Gao (JIRA)" <ji...@apache.org> on 2016/10/11 06:09:20 UTC

[jira] [Created] (KYLIN-2079) add explicit configuration knob for coprocessor timeout

Dayue Gao created KYLIN-2079:
--------------------------------

             Summary: add explicit configuration knob for coprocessor timeout
                 Key: KYLIN-2079
                 URL: https://issues.apache.org/jira/browse/KYLIN-2079
             Project: Kylin
          Issue Type: Sub-task
          Components: Storage - HBase
    Affects Versions: v1.5.4.1
            Reporter: Dayue Gao
            Assignee: Dayue Gao
             Fix For: v1.6.0


Current self-termination timeout for CubeVisitService is calculated as the product of three parameters:
* hbase.rpc.timeout
* hbase.client.retries.number (hardcode to 5)
* kylin.query.cube.visit.timeout.times

It has a few problems:
# due to this timeout being longer than hbase.rpc.timeout, user sees "Error in coprocessor" instead of more descriptive GTScanSelfTerminatedException. moreover, the request (probably a bad query) will be retried 5 times, increasing pressure on regionserver
# it's not intuitive to set coprocessor timeout by adjusting kylin.query.cube.visit.timeout.times

I propose the following changes:
# add a new kylin configuration "kylin.query.coprocessor.timeout.seconds" to explicitly set coprocessor timeout. It defaults to 0, which means no value, use hbase.rpc.timeout x 0.9 instead. When user sets it to a positive number, kylin will use min(hbase.rpc.timeout x 0.9, kylin.query.coprocessor.timeout.seconds) as coprocessor timeout
# remove "kylin.query.cube.visit.timeout.times". For cube visit timeout (ExpectedSizeIterator), it's really a last resort, in case coprocessor didn't terminate itself. I don't see too much needs for user to control it, set it to coprocessor timeout x 10 should be a large enough.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)