[
https://issues.apache.org/jira/browse/HBASE-29672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Roudnitsky updated HBASE-29672:
--------------------------------------
Description:
There is a large class of filters:
{code:java}
RowFilter
ValueFilter
QualifierFilter
FamilyFilter
DependentColumnFilter
ColumnValueFilter
SingleColumnValueFilter
SingleColumnValueExcludeFilter
{code}
Which take a ByteArrayComparable comparator as an argument (e.g
BinaryComparator, RegexStringComparator, BinaryComponentComparator) and apply
the given comparator at query runtime on the server. Due to filter
misconfiguration/data shape/comparator bugs, a comparator may throw a runtime
exception which filters are not currently handling. In this case the runtime
exception gets propagated all the way up the call stack, leading to an
unexpected throwable at the topmost RpcServer layer and an unclear remote
exception on the client with a long mysterious server exception trace (the call
stack includes everything from the topmost RpcServer layer all the way down to
the comparator layer, see HBASE-29678 for an example).
+Proposal+
We should handle comparison runtime exceptions at the filter layer and treat
them as HBaseIOException, and propagate a clear exception message and stack
trace to the client. This is beneficial for any type of runtime exception that
can occur in a comparator, and will also lets us handle cases where we know
that a client retry is guaranteed to fail and let us prevent bad requests from
being excessively retried (such as HBASE-29654 , HBASE-29678).
was:
There is a large class of filters:
{code:java}
RowFilter
ValueFilter
QualifierFilter
FamilyFilter
DependentColumnFilter
ColumnValueFilter
SingleColumnValueFilter
SingleColumnValueExcludeFilter
{code}
Which take a ByteArrayComparable comparator as an argument (e.g
BinaryComparator, RegexStringComparator, BinaryComponentComparator) and apply
the given comparator at query runtime on the server. Due to filter
misconfiguration/data shape/comparator bugs, a comparator may throw a runtime
exception which filters are not currently handling. In this case the runtime
exception gets propagated all the way up the call stack, leading to an
unexpected throwable at the topmost RpcServer layer and a very unclear remote
exception on the client with a very long mysterious server exception trace.
+Proposal+
We should handle comparison runtime exceptions at the filter layer and treat
them as HBaseIOException, and propagate a clear exception message and stack
trace to the client. This is beneficial for any type of runtime exception that
can occur in a comparator, and will also lets us handle cases where we know
that a client retry is guaranteed to fail and let us prevent bad requests from
being excessively retried (such as HBASE-29654 , HBASE-29678).
> Handle runtime comparison failures during filtering gracefully
> --------------------------------------------------------------
>
> Key: HBASE-29672
> URL: https://issues.apache.org/jira/browse/HBASE-29672
> Project: HBase
> Issue Type: Improvement
> Components: Filters
> Reporter: Daniel Roudnitsky
> Assignee: Daniel Roudnitsky
> Priority: Major
> Labels: pull-request-available
>
> There is a large class of filters:
> {code:java}
> RowFilter
> ValueFilter
> QualifierFilter
> FamilyFilter
> DependentColumnFilter
> ColumnValueFilter
> SingleColumnValueFilter
> SingleColumnValueExcludeFilter
> {code}
> Which take a ByteArrayComparable comparator as an argument (e.g
> BinaryComparator, RegexStringComparator, BinaryComponentComparator) and apply
> the given comparator at query runtime on the server. Due to filter
> misconfiguration/data shape/comparator bugs, a comparator may throw a runtime
> exception which filters are not currently handling. In this case the runtime
> exception gets propagated all the way up the call stack, leading to an
> unexpected throwable at the topmost RpcServer layer and an unclear remote
> exception on the client with a long mysterious server exception trace (the
> call stack includes everything from the topmost RpcServer layer all the way
> down to the comparator layer, see HBASE-29678 for an example).
> +Proposal+
> We should handle comparison runtime exceptions at the filter layer and treat
> them as HBaseIOException, and propagate a clear exception message and stack
> trace to the client. This is beneficial for any type of runtime exception
> that can occur in a comparator, and will also lets us handle cases where we
> know that a client retry is guaranteed to fail and let us prevent bad
> requests from being excessively retried (such as HBASE-29654 , HBASE-29678).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
