droudnitsky commented on PR #7389: URL: https://github.com/apache/hbase/pull/7389#issuecomment-3418722421
Looked into these two options mentioned above: Option 1 - Treat any runtime exception that occurs specifically when applying a comparator for `CompareFilter` as `DoNotRetryIOException` - does not require a very big change since all the filters which extend `CompareFilter` (e.g `RowFilter`) use the same methods to invoke the comparator, and this limits the set of runtime exceptions that we rethrow as checked exceptions to only runtime exceptions coming from comparators being used by `CompareFilter` - I think it makes a lot of sense to cover all comparator runtime exceptions there - I will create a new jira/PR for handling this general `CompareFilter` case and keep this PR limited to adding a bounds check/useful error message to `BinaryComponentComparator` Option 2 - More generally wrap any runtime exception that happens during filter application as `DoNotRetryIOException` - requires more extensive changes , and would change the behavior of how runtime exceptions are handled across the entire filter layer. If my assumption that if a runtime exception occurs during filter application its extremely likely to happen again if the same scan RPC is retried with the same filters/data, this makes sense, but then maybe limit this only to user scans to prevent RPC retries/give client a clean exception, and for system scans keep the same behavior and not wrap the exception since system scans don't suffer from RPC retry problem and as to not change server behavior. @Apache9 wondering what you think about this -- 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]
