[
https://issues.apache.org/jira/browse/HBASE-14598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14955742#comment-14955742
]
Ian Friedman commented on HBASE-14598:
--------------------------------------
Working on testing a slightly more comprehensive patch [~stack], [~davelatham]
pointed out some other potential pitfalls in the existing code. Will post once
we've given it a quick run.
> ByteBufferOutputStream grows its HeapByteBuffer beyond JVM limitations
> ----------------------------------------------------------------------
>
> Key: HBASE-14598
> URL: https://issues.apache.org/jira/browse/HBASE-14598
> Project: HBase
> Issue Type: Bug
> Affects Versions: 0.98.12
> Reporter: Ian Friedman
> Assignee: Ian Friedman
> Attachments: 14598.txt
>
>
> We noticed that in returning a Scan against a region containing particularly
> large (wide) rows that it is possible during ByteBufferOutputStream.
> checkSizeAndGrow() to attempt to create a new ByteBuffer larger than the JVM
> allows which then throws a OutOfMemoryError. The code currently caps it at
> Integer.MAX_VALUE which is actually larger than the JVM allows. This lead to
> us dealing with cascading region server death as the RegionServer hosting the
> region died, opened on a new server, the client retried the scan, and the new
> RS died as well.
> I believe ByteBufferOutputStream should not try to create ByteBuffers that
> large and instead throw an exception back up if it needs to grow any bigger.
> The limit should probably be something like Integer.MAX_VALUE-8, as that is
> what ArrayList uses. ref:
> http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/util/ArrayList.java#221
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
