You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@orc.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2016/09/30 20:33:20 UTC
[jira] [Commented] (ORC-103) Make ORC Reader resilient to 0 length
files
[ https://issues.apache.org/jira/browse/ORC-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15536995#comment-15536995 ]
ASF GitHub Bot commented on ORC-103:
------------------------------------
GitHub user prasanthj opened a pull request:
https://github.com/apache/orc/pull/61
ORC-103: Make ORC Reader resilient to 0 length files
@omalley Can you please take a look?
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/prasanthj/orc master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/orc/pull/61.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #61
----
commit 7d83c2a83ca25e46ee08d96460c8c7f57fe5f9af
Author: Prasanth Jayachandran <pr...@apache.org>
Date: 2016-09-30T20:31:45Z
ORC-103: Make ORC Reader resilient to 0 length files
----
> Make ORC Reader resilient to 0 length files
> -------------------------------------------
>
> Key: ORC-103
> URL: https://issues.apache.org/jira/browse/ORC-103
> Project: Orc
> Issue Type: Bug
> Components: Reader
> Affects Versions: 1.2.1
> Reporter: Prasanth Jayachandran
> Assignee: Prasanth Jayachandran
>
> Orc reader will throw IndexOutOfBounds if used directly. Following is the exception
> {code}
> Caused by: java.lang.IndexOutOfBoundsException
> at java.nio.Buffer.checkIndex(Buffer.java:540)
> at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:139)
> at org.apache.orc.impl.ReaderImpl.extractFileTail(ReaderImpl.java:515)
> at org.apache.orc.impl.ReaderImpl.<init>(ReaderImpl.java:368)
> at org.apache.orc.OrcFile.createReader(OrcFile.java:222)
> at org.apache.orc.TestReader.testReadZeroLengthFile(TestReader.java:57)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:19)
> ... 22 more
> {code}
> Input format usually avoids such files but not generating splits but if someone uses the Reader directly on invalid files it should be resilient too. OrcOutputFormat will not create a 0 length so this shouldn't be a problem for files written by Orc itself.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)