[
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 a very unclear remote
exception on the client with a very long server exception trace.
We should handle comparison runtime exceptions and treat them as
HBaseIOException, and propagate a clear exception message to the client. This
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).
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 RpcServer layer and a very unclear remote exception
on the client with a very long server exception trace.
We should handle comparison runtime exceptions and treat them as
HBaseIOException, and propagate a clear exception message to the client. This
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).
> Handle 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 a very unclear remote
> exception on the client with a very long server exception trace.
> We should handle comparison runtime exceptions and treat them as
> HBaseIOException, and propagate a clear exception message to the client. This
> 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).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
