[
https://issues.apache.org/jira/browse/HBASE-27048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17566626#comment-17566626
]
Viraj Jasani commented on HBASE-27048:
--------------------------------------
[~bbeaudreault] I am yet to look into the patch in detail but it seems that two
tests (TestIncrementTimeRange and TestAppendTimeRange) have regression after
this commit. The reason why our QA might not have caught this is because these
tests are somehow in exclude tests list but our internal lightfork doesn't have
them in excluded list and hence I observed the build somehow gets stuck with
these two tests exceeding timeouts consistently. Could you please take a look?
FYI [~apurtell] before we create RC for 2.5.0, we can sort this out.
> Server side scanner time limit should account for time in queue
> ---------------------------------------------------------------
>
> Key: HBASE-27048
> URL: https://issues.apache.org/jira/browse/HBASE-27048
> Project: HBase
> Issue Type: Improvement
> Reporter: Bryan Beaudreault
> Assignee: Bryan Beaudreault
> Priority: Major
> Fix For: 2.5.0, 3.0.0-alpha-4, 2.4.14
>
>
> When a scan request comes in with a timeout specified and heartbeats/partials
> allowed, we calculate a time limit for running the scan to be half of that
> timeout. The idea is to return before the timeout expires.
> The calculation of that time limit is "now + timeout / 2", where now is the
> point at which the scan is starting to run. What's missed here is the scan
> may have spent upwards of a few seconds in the IPC queue before being
> serviced. In this case, the time limit may extend beyond the timeout of the
> request and the server will not return in time.
> We should calculate the time limit from ServerCall.getReceiveTime instead to
> avoid these timeouts.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
