[HBASE-28085] Configurably use scanner timeout as rpc timeout for scanner next calls

• Type: Improvement
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 2.6.0
• Labels: patch-available

Release Note

Adds a new configuration key: hbase.client.use.scanner.timeout.period.for.next.calls. The default value is false to preserve original behavior. When set to true, ClientScanner will use hbase.client.scanner.timeout.period for the RPC timeout of individual next() RPC calls. This is in-line with the behavior of AsyncTable and future 3.0 release.

• Assignee: Bryan Beaudreault
• Reporter: Bryan Beaudreault
• Created: 14/Sep/23 13:31
• Updated: 09/Nov/23 22:40
• Resolved: 09/Nov/23 22:37

Description

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:

// 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. 

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.

Issue Links

• links to: GitHub Pull Request #5402