[
https://issues.apache.org/jira/browse/HBASE-16775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15586519#comment-15586519
]
Appy commented on HBASE-16775:
------------------------------
It'll be good to segregate all testing-only members in a separate class like
this
{noformat}
static class Testing {
final String CONF_TEST_FAILURE = "test.snapshot.export.failure";
final String CONF_TEST_RETRY = "test.snapshot.export.failure.retry";
final String TESTING_EXCEPTION_CREATED_FILENAME = "exceptionCreated";
}
{noformat}
Taking a step back, what are we trying to test here? To me v3 change looks like
they are just testing this, if an exception is thrown from a mapper, then
miniMRcluster should rerun the mapper.
At least, we should do more verifications like in
{{testExportFileSystemState(..)}} when testExportRetry() finishes.
And in testExportFailure(), we should test that cleanup works. So maybe inject
bogus files.
Also, the fact that we inject failures in the very start, before doing any work
doesn't sound a good way because when failures are thrown in real use cases,
directories would have been created, files would have been written to some
extent, etc.
So it'd much better if we can,
1. instead of directly throwing exception, inject some kind of failure which
makes the 'non-test-hook' throw exception
2. do it in later stages of copy.
One such place is copyData() function, maybe add a few extra bytes on outStream
so that source and dest sizes don't match in the end.
> Flakey test with TestExportSnapshot#testExportRetry and
> TestMobExportSnapshot#testExportRetry
> ----------------------------------------------------------------------------------------------
>
> Key: HBASE-16775
> URL: https://issues.apache.org/jira/browse/HBASE-16775
> Project: HBase
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: huaxiang sun
> Assignee: huaxiang sun
> Attachments: HBASE-16775.master.001.patch,
> HBASE-16775.master.002.patch, HBASE-16775.master.003.patch, disable.patch
>
>
> The root cause is that conf.setInt("mapreduce.map.maxattempts", 10) is not
> taken by the mapper job, so the retry is actually 0. Debugging to see why
> this is the case.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
