Review Board 1.6.3

Refactor "Corrupt Data" Tests in TestHLogSplit

Review Request #1115 - submitted 3 years, 5 months ago

Alex Newman Reviewers
hbase
hbase-2935 nspiegelberg
None hbase
So I took the approach taken with the instrumented sequence file rider. Not sure if exposing those methods in the WALReader is cool so I am down with other suggestions.

- Add a FaultySequenceFileLogReader
- Un-commented the 2935 tests
Running on our internal hudson as I type this. Also I ran the TestHLogSplit test locally. I'll update the review if hudson is green.
Review request changed
Updated 3 years, 5 months ago (October 29th, 2010, 3:03 p.m.)
sta^ck and ryan's suggestions
Posted 3 years, 5 months ago (October 29th, 2010, 3:44 p.m.)

   

  
woops pretend this says 
    return FailureType.valueOf(conf.get("faultysequencefilelogreader.failuretype", FailureType.NONE.name()));
Ship it!
Posted 3 years, 5 months ago (October 31st, 2010, 9:18 p.m.)
I'm okay with the general concept/direction.  I think you should get rid of resetLogReaderClass(), but other than that, it looks pretty clean :)  I think there's more edge cases with IOE/ParseExceptions that we could theoretically handle, but this is a positive step and mitigates the regression.
  1. Right on, what are some edge cases? What's the best way to nuke that state? Eventually, with distributed log splitting, this will eventually need to work in a distributed way.
Posted 3 years, 5 months ago (November 4th, 2010, 3:25 p.m.)
Anything else need to be done here?