Resolution: Cannot Reproduce
Affects Version/s: 0.20.6
Fix Version/s: None
I see a lot of UnknownScannerException messages in the log at ERROR level when I'm running a MapReduce job that scans an HBase table. These messages are logged under normal conditions, and according to Jean-Daniel Cryans, should probably be logged at a less severe log level like WARN.
Example error message:
Reference to the HBase users mailing list thread where this was originally discussed:
This is a simple, change, so I didn't include a formal patch. If one is required, I will gladly create and attach one.
|Field||Original Value||New Value|
|Priority||Major [ 3 ]||Trivial [ 5 ]|
[ From mailing list:
I agree it needs some clarification, since that stuff evolved in
disparate ways. Historically UnknownScannerException has been fatal
and wasn't recovered from. Right now, the client will recover only if
the timeout hasn't expired (so you get this only when the region moves
or it took more than 60 seconds to call next). On top of that,
TableRecordReaderImpl will recover even if there's a timeout by
restarting a new scanner. The DoNotRetryIOException is only a way for
HBase to tell the HBase client that it shouldn't retry in the normal
retry code inside HConnectionManager, it's not a way to tell the
actual user that he shouldn't create a new scanner and retry.
Thus, the way I understand it, the fact that TRRI recovers from USE is
a design choice the same way someone using Scan in his code could
decide to retry scanning with a new scanner upon getting that error. I
like the way it currently works because if USE comes out of the
ResultScanner, it means that it took more than 60 seconds to process
one next() invocation so something is wrong (but the user can ignore
it like TRRI does).
That said, the exception should be printed as a WARN in the region
server log and probably shouldn't care printing a stack trace.
|Status||Open [ 1 ]||Resolved [ 5 ]|
|Resolution||Cannot Reproduce [ 5 ]|
|Transition||Time In Source Status||Execution Times||Last Executer||Last Execution Date|
|1278d 23h 27m||1||stack||19/Mar/14 23:50|