[
https://issues.apache.org/jira/browse/HBASE-6345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13409915#comment-13409915
]
Todd Lipcon commented on HBASE-6345:
------------------------------------
bq. Couple comments for Todd and others. I did some my investigation on this
topic last week and found testing data streaming pipeline in hdfs requires fi.
Is there any other reasons not to use fi besides "hard to maintain"?
Well, it used to, but when we mavenized, we lost the ability to actually run
those tests. So if they're still in the code base, they're not getting compiled
or run, and I doubt they work anymore.
bq. I have just got maven + aspectJ working for hbase. It does require some
learning to write fi test; but it doesn't seem to be that hard.
It's not that it's super hard, but it does take many hours of learning to be
able to write even the simplest test. I found this to be a big pain when
refactoring or otherwise changing the Hadoop code. I wanted to restructure a
bit of that code at one point, and it basically took me a day to learn enough
AspectJ to figure out how to do it - they are lots of new concepts like
"advices" and "pointcuts" which need to be understood before you can get very
far. In contrast, the simple Java approach is immediately obvious to anyone who
looks at the code, and also "plays nice" with IDE features - for example, you
can right click on the fault point you're interested in, search for references,
and see all of the unit tests which touch this fault injection point.
bq. It looks like CheckpointFaultInjector example above requires code change in
hadoop core. fi doesn't require that. I find it useful to not require core code
change to inject failure at any place. On frequently called function, adding
call to fault injector in the core code might have perf impact.
In a JITted language, the perf impact of this should be zero. The reason being
is that the JVM can figure out that there's only one implementation of the
method being called (since the actual fault injection implementation hasn't
been classloaded). So, it directly inlines the empty method, and thus
disappears entirely.
I've heard the argument before that the fault points clutter the production
code, and people find that ugly. I personally take the opposite opinion here:
the fact that there are fault hooks in the non-test code means that anyone else
coming alone will better understand what kind of faults are important to
consider for the code in question. And, when they change the code, they'll be
much more aware of the potential faults they need to take into account.
> Utilize fault injection in testing using AspectJ
> ------------------------------------------------
>
> Key: HBASE-6345
> URL: https://issues.apache.org/jira/browse/HBASE-6345
> Project: HBase
> Issue Type: Bug
> Reporter: Zhihong Ted Yu
>
> HDFS uses fault injection to test pipeline failure in addition to mock, spy.
> HBase uses mock, spy. But there are cases where mock, spy aren't convenient.
> Some example from DFSClientAspects.aj :
> {code}
> pointcut pipelineInitNonAppend(DataStreamer datastreamer):
> callCreateBlockOutputStream(datastreamer)
> && cflow(execution(* nextBlockOutputStream(..)))
> && within(DataStreamer);
> after(DataStreamer datastreamer) returning :
> pipelineInitNonAppend(datastreamer) {
> LOG.info("FI: after pipelineInitNonAppend: hasError="
> + datastreamer.hasError + " errorIndex=" + datastreamer.errorIndex);
> if (datastreamer.hasError) {
> DataTransferTest dtTest = DataTransferTestUtil.getDataTransferTest();
> if (dtTest != null)
> dtTest.fiPipelineInitErrorNonAppend.run(datastreamer.errorIndex);
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
