DieterDePaepe commented on code in PR #7762:
URL: https://github.com/apache/hbase/pull/7762#discussion_r3379687079
##########
hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/WALInputFormat.java:
##########
@@ -154,13 +155,22 @@ private WALStreamReader openReader(Path path, long
startPosition) throws IOExcep
int attempt = 0;
Exception ee = null;
WALStreamReader reader = null;
+ boolean supressException = false;
Review Comment:
Typo.
##########
hbase-mapreduce/src/main/java/org/apache/hadoop/hbase/mapreduce/WALInputFormat.java:
##########
@@ -154,13 +155,22 @@ private WALStreamReader openReader(Path path, long
startPosition) throws IOExcep
int attempt = 0;
Exception ee = null;
WALStreamReader reader = null;
+ boolean supressException = false;
while (reader == null && attempt++ < maxAttempts) {
try {
// Detect if this is a new file, if so get a new reader else
// reset the current reader so that we see the new data
reader =
WALFactory.createStreamReader(path.getFileSystem(conf), path,
conf, startPosition);
return reader;
+ } catch (WALHeaderEOFException wheofe) {
Review Comment:
I've looked into the potential causes for this exception. The only
legitimate case this can occur in normal operation is when using the legacy WAL
writer, where there's a minimal time period between opening and flushing the
first entry. Other cases are due to crashing Region Servers.
I prefer skipping the retry because:
- it causes the test to run for over a minute.
- in case the empty WAL file originated from a crash, a retry will not solve
anything, and just cause a long delay.
- given the only legitimate case for the empty WAL (the legacy WAL writer)
simply caused a crash before, it's not a regression to just skip the WAL file
instead.
--
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]
