toddlipcon commented on a change in pull request #597: HDFS-3246: pRead
equivalent for direct read path
URL: https://github.com/apache/hadoop/pull/597#discussion_r269397015
##########
File path:
hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/CryptoInputStream.java
##########
@@ -341,6 +343,26 @@ public int read(long position, byte[] buffer, int offset,
int length)
"positioned read.");
}
}
+
+ /** Positioned read using ByteBuffers. It is thread-safe */
+ @Override
+ public int read(long position, final ByteBuffer buf)
+ throws IOException {
+ checkStream();
+ try {
+ int pos = buf.position();
+ final int n = ((ByteBufferPositionedReadable) in).read(position, buf);
+ if (n > 0) {
+ // This operation does not change the current offset of the file
+ decrypt(position, buf, n, pos);
+ }
+
+ return n;
+ } catch (ClassCastException e) {
Review comment:
hrm. I think we should probably do a follow-up JIRA to fix this, not for
performance reasons, but because the try{...} block encompasses a lot of code.
Let's say we accidentally screw up something in our encryption config and we
get a ClassCastException somewhere inside decrypt. We'll swallow the real
exception and claim that positioned read isn't supported, which isn't quite
right.
So, I agree an instanceof check up front is probably the clearest from a
code perspective and also avoids the above issue.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: common-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: common-issues-h...@hadoop.apache.org
