[
https://issues.apache.org/jira/browse/HBASE-14735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14988285#comment-14988285
]
stack commented on HBASE-14735:
-------------------------------
I've not seen these before:
{code}
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "DataXceiver for client DFSClient_NONMAPREDUCE_-2059214831_1 at
/127.0.0.1:34403 [Cleaning up]"
SUREFIRE-859: Exception: java.lang.OutOfMemoryError thrown from the
UncaughtExceptionHandler in thread "DataStreamer for file
/user/jenkins/test-data/c39c6ed9-be99-4649-9694-9e992e301990/WALs/asf900.gq1.ygridcore.net,60113,1446481333200/asf900.gq1.ygridcore.net%2C60113%2C1446481333200.meta.1446481338603.meta
block BP-1836657432-67.195.81.144-1446481320143:blk_1073741832_1008"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "DataXceiver for client DFSClient_NONMAPREDUCE_-382677715_1 at
/127.0.0.1:51885 [Cleaning up]"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "DataXceiver for client DFSClient_NONMAPREDUCE_-2059214831_1 at
/127.0.0.1:42731 [Cleaning up]"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "DataXceiver for client DFSClient_NONMAPREDUCE_-914917836_1 at
/127.0.0.1:51880 [Cleaning up]"
Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler
in thread "DataXceiver for client DFSClient_NONMAPREDUCE_-1454509619_1 at
/127.0.0.1:51876 [Cleaning up]"
{code}
Trying again.
> Region may grow too big and can not be split
> --------------------------------------------
>
> Key: HBASE-14735
> URL: https://issues.apache.org/jira/browse/HBASE-14735
> Project: HBase
> Issue Type: Bug
> Components: Compaction, regionserver
> Affects Versions: 1.1.2, 0.98.15
> Reporter: Shuaifeng Zhou
> Assignee: Shuaifeng Zhou
> Attachments: 14735-master.patch, 14735-master.patch
>
>
> When a compaction completed, may there are also many storefiles in the store,
> and CompactPriority < 0, then compactSplitThread will do a "Recursive
> enqueue" compaction request instead of request a split:
> {code:title=CompactSplitThread.java|borderStyle=solid}
> if (completed) {
> // degenerate case: blocked regions require recursive enqueues
> if (store.getCompactPriority() <= 0) {
> requestSystemCompaction(region, store, "Recursive enqueue");
> } else {
> // see if the compaction has caused us to exceed max region size
> requestSplit(region);
> }
> {code}
> But in some situation, the "recursive enqueue" request may return null, and
> not build up a new compaction runner. For example, an other compaction of the
> same region is running, and compaction selection will exclude all files older
> than the newest files currently compacting, this may cause no enough files
> can be selected by the "recursive enqueue" request. When this happen, split
> will not be trigged. If the input load is high enough, compactions aways
> running on the region, and split will never be triggered.
> In our cluster, this situation happened, and a huge region more than 400GB
> and 100+ storefiles appeared. Version is 0.98.10, and the trank also have the
> problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
