hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-11042) CryptoInputStream throwing wrong exception class on errors
Date Sat, 07 Feb 2015 19:37:35 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-11042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14310890#comment-14310890

Steve Loughran commented on HADOOP-11042:

-sorry for not replying about this; I think I'd missed the patch in my inbox.

Looks good. I was a bit worried about the refactoring but it makes sense -and the way the
contract tests are designed, FS-specific subclasses will pick up the changes without any changes
needed to their code (I'll do a test run of the s3 and openstack clients just to make sure
there before it gets its +1.

# can you switch to using FSExceptionMessages constants for your exception text? With the
same text everywhere we can simplify documentation and maybe even add wiki links in future.

# testRenameFileBeingAppended()` tries to rename a file that is being written to. The patched
version doesn't. (to be fair, the expected outcome of that operation isn't defined AFAIK).
It may be easiest to leave that as is and in the subclass, just skip it (ie {{Assume.assumeTrue(false)}})

> CryptoInputStream throwing wrong exception class on errors
> ----------------------------------------------------------
>                 Key: HADOOP-11042
>                 URL: https://issues.apache.org/jira/browse/HADOOP-11042
>             Project: Hadoop Common
>          Issue Type: Bug
>          Components: fs
>            Reporter: Steve Loughran
>            Assignee: Yi Liu
>         Attachments: HADOOP-11042.001.patch
> Having had a quick look at the {{CryptoInputStream}} class, it's not in sync with all
the other filesystem's exception logic, as specified in {{src/site/markdown/filesystem/fsdatainputstream.md}}
> Operations MUST throw an {{IOException}} on out of bounds reads, ideally {{EOFException}}
> # {{read(byte[] b, int off, int len)}} 
> # {{seek(long pos) }}
> # {{seekToNewSource}}
> The tests you want to extend to verify expected behaviour are in {{AbstractContractOpenTest}}
and {{AbstractContractSeekTest}}
> also, the {{HasEnhancedByteBufferAccess}} implementations may want to think about using
{{checkStream()}} before acting on a potentially closed stream.

This message was sent by Atlassian JIRA

View raw message