stoty commented on PR #7475: URL: https://github.com/apache/hbase/pull/7475#issuecomment-3558955235
Phoenix currently has a home-grown solution (from back when Phoenix was primarily targeting HBase 1.x, which did not have the heartbeat feature ) for the heartbeat problem which uses a magic "Dummy" Cell to indicate heartbeat and cursor information, and has introduced its own configuration option for that time limit. This works fine for Hbase 1 and 2, but in Hbase 3 it interferes with the heartbeat logic in the HBase client, causing it to skip rows. The goal is the same as in HBase: allow long-running scans without having to set unrealistically long timeouts. In a green-field implementation the HBase defaults would probably be good enough for Phoenix, but for backward compatibility reasons I'd like to be able to retain the ability to set the scan.next() time limit based on the existing parameter passed by the client in a scan attribute . The current logic is centered in https://github.com/apache/phoenix/blob/master/phoenix-core-server/src/main/java/org/apache/phoenix/coprocessor/PagingRegionScanner.java Here, instead of using PagingFilter, Phoenix could modify the ScannerContext time limit to the same value, and rely on the HBase functionality. We can do that today, but we'd have to read all values from the existing ScannerContext and then create a new one, which is quite a lot of cpu cycles: - we'd have to get the limits and progress ftom the original ScannerContext, - then create a new one with the new time limit, - then after the call copy the progress back to the original ScannerContext -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
