[ https://issues.apache.org/jira/browse/HDFS-2034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045043#comment-13045043 ]
Todd Lipcon commented on HDFS-2034: ----------------------------------- In general regarding asserts: - definitely don't rely on asserts to sanity-check user input - most people run without asserts on - I wouldn't be too concerned about performance of asserts unless it's doing something like an RPC -- since they're only usually on in unit tests, it's reasonable to trade off for safety over performance Some notes on the specific patch: - In this case, I think the assert that Daryn suggested is reasonable -- given it's a private method, it shouldn't ever have this invalid input, since the input is already sanity checked in the {{read}} code path, right? - the {{new ArrayList<LocatedBlock>()}} is unneeded in the usual case, since the blocks variable is overwritten anyway. Perhaps you could push this to an {{else}} clause? > length in getBlockRange becomes -ve when reading only from currently being > written blk > -------------------------------------------------------------------------------------- > > Key: HDFS-2034 > URL: https://issues.apache.org/jira/browse/HDFS-2034 > Project: Hadoop HDFS > Issue Type: Bug > Reporter: John George > Assignee: John George > Priority: Minor > Attachments: HDFS-2034-1.patch, HDFS-2034-1.patch, HDFS-2034-2.patch, > HDFS-2034.patch > > > This came up during HDFS-1907. Posting an example that Todd posted in > HDFS-1907 that brought out this issue. > {quote} > Here's an example sequence to describe what I mean: > 1. open file, write one and a half blocks > 2. call hflush > 3. another reader asks for the first byte of the second block > {quote} > In this case since offset is greater than the completed block length, the > math in getBlockRange() of DFSInputStreamer.java will set "length" to > negative. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira