[
https://issues.apache.org/jira/browse/HBASE-28085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Beaudreault updated HBASE-28085:
--------------------------------------
Fix Version/s: 2.6.0
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Configurably use scanner timeout as rpc timeout for scanner next calls
> ----------------------------------------------------------------------
>
> Key: HBASE-28085
> URL: https://issues.apache.org/jira/browse/HBASE-28085
> Project: HBase
> Issue Type: Improvement
> Reporter: Bryan Beaudreault
> Assignee: Bryan Beaudreault
> Priority: Major
> Labels: patch-available
> Fix For: 2.6.0
>
>
> In the AsyncTable implementation, scanner next() calls use
> "hbase.client.scanner.timeout.period" as the rpc timeout. The reason is
> described in comments, and makes a lot of sense:
> {code:java}
> // As we have a call sequence for scan, it is useless to have a different rpc
> timeout which is
> // less than the scan timeout. If the server does not respond in time(usually
> this will not
> // happen as we have heartbeat now), we will get an
> OutOfOrderScannerNextException when
> // resending the next request and the only way to fix this is to close the
> scanner and open a
> // new one. {code}
> The branch-2 HTable implementation still uses the old behavior – the next()
> call passes the read rpc timeout as the rpc timeout, and uses the scanner
> timeout period as the operation timeout. This can lead to the above behavior.
> It would be nice to provide users a migration path to AsyncTable's behavior,
> in the form of a config flag which causes HTable to use
> "hbase.client.scanner.timeout.period" as rpc timeout for next() calls like
> AsyncTable does.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
