[
https://issues.apache.org/jira/browse/HBASE-7481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604647#comment-13604647
]
Andrea Gazzarini commented on HBASE-7481:
-----------------------------------------
Hi all,
I added the IOException in all methods of Filter class except for
* _areSerializedFieldsEqual(Filter other)_ because I'm not sure if it is useful
here
* _hasFilterRow()_ because reading the documentation and looking at all
implementers it doesn't seems it needs to throw IOException
Othen than _org.apache.hadoop.hbase.filter.Filter_ I changed the following
classes:
1) _org.apache.hadoop.hbase.filter.FilterBase_
As described in a previous post, declaring a filter throwing IOException does
not mean the implementers have to throws IOExceptions, so basically after
changing the Filter class, the FilterBase doesn't need any change. But this is
true til some concrete implementer acts as a decorator of Filter / FilterBase
class and uses a Filter instance as a decoratee. As an example see
org.apache.hadoop.hbase.filter.WhileMatchFilter: changing only the Filter class
produces compile error because the wrapped filter instance needs to throw
IOException in decorated methods (and the FilterBase subclass is not allowed to
do that). So, at the end, the FilterBase methods needs to declare the
IOException too.
2) _org.apache.hadoop.hbase.filter.WhileMatchFilter_
3) _org.apache.hadoop.hbase.filter.SkipFilter_
4) _org.apache.hadoop.hbase.regionserver.RegionScanner_ and
_org.apache.hadoop.hbase.regionserver.HRegion_
HRegion needs this refactor because
* the HRegion.isFilterDone is calling Filter.filterAllRemaining(). Throwing
IOException here solves all compile problems because methods that are calling
this method (i.e. CustomScanner.isFilterDone, RegionScannerImpl.nextRaw,
HRegionServer.scan) are already throwing IOException in their signature.
* HRegion.resetFilters calls Filter.reset() and therefore needs IOException in
its signature. No problems with the calling hierarchy for the same reason above.
* HRegion.filterRowKey: calls Filter.filterRowKey so same story of the previous
points. The calling method is already declaring the IOException.
5) _org.apache.hadoop.hbase.regionserver.ScanQueryMatcher_
The method getNextKeyHint() calls the corresponding Filter.getNextKeyHint. The
StoreScanner.next is the only caller of this method and it is already throwing
IOException.
6) _org.apache.hadoop.hbase.mapreduce.Import_
filterKv(KeyValue kv) *throws IOException* : the calling map() already throws
IOException so changing the signature of filterKv should be enough
7) _org.apache.hadoop.hbase.coprocessor.TestCoprocessorInterface_
The inner class CustomScanner, as implementer of RegionScanner, needs to
decalre IOException in isFilterDone() method
8) _org.apache.hadoop.hbase.filter.TestFilter.SlowScanFilter_
Added throws IOException to filterRow() method
9) _org.apache.hadoop.hbase.filter.TestPageFilter_
testFiltersBeyondPageSize() *throws IOException*
10) _org.apache.hadoop.hbase.protobuf.ProtobufUtil_
The toFilter method calls Filter.toByteArray() and is called by some Filter
implementers so I changed its signature by adding "throws IOException"
----------------------
After making those changes above, _mvn test_ reports a green bar
PS: It is perfectly possible I made a lot of mistakes in my "analysis"...so
please feel free to suggest me, I would like to understand better HBase and
therefore give a hand
> throw IOExceptions from Filter methods?
> ---------------------------------------
>
> Key: HBASE-7481
> URL: https://issues.apache.org/jira/browse/HBASE-7481
> Project: HBase
> Issue Type: Bug
> Reporter: Lars Hofhansl
> Fix For: 0.95.0, 0.98.0, 0.94.7
>
>
> Currently there is no way to throw custom IOExceptions from any of the filter
> methods.
> For implementers of custom filters that presents a problem.
> For example there are scenarios where the filter would want to indicate to
> the client that there it should not retry. Currently there is no way of doing
> that.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
