|
[
Permlink
| « Hide
]
Jothi Padmanabhan added a comment - 21/Nov/08 04:03 AM
This makes sense. However, I think we should do a measurement of the performance overhead experimentally to validate the theory. If there is no significant overhead due to checksum validation, we might be better off doing it in the Servlet as well to help prevent transmission of the corrupted output. No?
Disregard my previous comment, if we use NIO, we would not be reading the file at the servlet all and so cannot validate the checksum.
Removes the checksum validation from MapOutputServlet
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12395171/4699-0.patch against trunk revision 724229. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 Eclipse classpath. The patch retains Eclipse classpath integrity. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Hadoop-Patch/3688/testReport/ This message is automatically generated. Changes look fine.
I see that you have removed the Debug statements introduced by Arun for And curious, did you benchmark this patch against trunk for performance?
HADOOP-4754 was going to address this directly, but it would have conflicted with other patches, so I abandoned it. If you think it merits a separate issue, then I can rework both patches.
No. It probably won't have a measurable impact.
If the problem underlying |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||