[
https://issues.apache.org/jira/browse/HADOOP-14872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215175#comment-16215175
]
Steve Loughran commented on HADOOP-14872:
-----------------------------------------
LGTM. Once this is in and I get back to defining hsync/sync I'll add SHOULD
implement this API.
* CryptoInputStream.unbuffer. Should the cleanBufferPool/cleanDescriptorPool be
in a finally block just in case the nested stream raises an exception on
unbuffer?
Maybe: factor out the unbuffer logic into something which can be used broadly.
This will give us a single place to implement/maintain policy
{code}
public void unbuffer(InputStream s) {
try {
if (....)
} catch (UnsupportedOperationException ex) {
LOG.warn("Stream says it unbuffers, but it doesn't")
}
}
{code}
FileSystem.md
* L1247: I'm using it in FileSystem itself in S3a, so make the sentence broader
& not need updates later. e.g "Capabilities which an OutputStream, InputStream
or other FileSystem class with the interface supports."
* L1257: Similar. True if the current instance of the class supports the
specific capability.
* L1270: "Implements `FileSystem.CanUnbuffer`
CryptoStreamsTestBase
* L777. Use {{LOG.error}}
> CryptoInputStream should implement unbuffer
> -------------------------------------------
>
> Key: HADOOP-14872
> URL: https://issues.apache.org/jira/browse/HADOOP-14872
> Project: Hadoop Common
> Issue Type: Improvement
> Components: fs
> Affects Versions: 2.6.4
> Reporter: John Zhuge
> Assignee: John Zhuge
> Attachments: HADOOP-14872.001.patch, HADOOP-14872.002.patch,
> HADOOP-14872.003.patch, HADOOP-14872.004.patch, HADOOP-14872.005.patch,
> HADOOP-14872.006.patch, HADOOP-14872.007.patch, HADOOP-14872.008.patch,
> HADOOP-14872.009.patch, HADOOP-14872.010.patch, HADOOP-14872.011.patch,
> HADOOP-14872.012.patch
>
>
> Discovered in IMPALA-5909.
> Opening an encrypted HDFS file returns a chain of wrapped input streams:
> {noformat}
> HdfsDataInputStream
> CryptoInputStream
> DFSInputStream
> {noformat}
> If an application such as Impala or HBase calls HdfsDataInputStream#unbuffer,
> FSDataInputStream#unbuffer will be called:
> {code:java}
> try {
> ((CanUnbuffer)in).unbuffer();
> } catch (ClassCastException e) {
> throw new UnsupportedOperationException("this stream does not " +
> "support unbuffering.");
> }
> {code}
> If the {{in}} class does not implement CanUnbuffer, UOE will be thrown. If
> the application is not careful, tons of UOEs will show up in logs.
> In comparison, opening an non-encrypted HDFS file returns this chain:
> {noformat}
> HdfsDataInputStream
> DFSInputStream
> {noformat}
> DFSInputStream implements CanUnbuffer.
> It is good for CryptoInputStream to implement CanUnbuffer for 2 reasons:
> * Release buffer, cache, or any other resource when instructed
> * Able to call its wrapped DFSInputStream unbuffer
> * Avoid the UOE described above. Applications may not handle the UOE very
> well.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
