[
https://issues.apache.org/jira/browse/HBASE-14263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14705379#comment-14705379
]
stack commented on HBASE-14263:
-------------------------------
Patch looks reasonable mighty [~vrodionov] Any chance of our getting a test in
here so can guard against regression? Thanks.
> ExploringCompactionPolicy logic around file selection is broken
> ---------------------------------------------------------------
>
> Key: HBASE-14263
> URL: https://issues.apache.org/jira/browse/HBASE-14263
> Project: HBase
> Issue Type: Bug
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Fix For: 2.0.0
>
> Attachments: HBASE-14263.patch
>
>
> It seems that logic around selection of store file candidates is broken:
> {code}
> // Compute the total size of files that will
> // have to be read if this set of files is compacted.
> long size = getTotalStoreSize(potentialMatchFiles);
> // Store the smallest set of files. This stored set of files will be
> used
> // if it looks like the algorithm is stuck.
> if (mightBeStuck && size < smallestSize) {
> smallest = potentialMatchFiles;
> smallestSize = size;
> }
> if (size > comConf.getMaxCompactSize()) {
> continue;
> }
> ++opts;
> if (size >= comConf.getMinCompactSize()
> && !filesInRatio(potentialMatchFiles, currentRatio)) {
> continue;
> }
> {code}
> This is from applyCompactionPolicy method. As you can see, both min
> compaction size and max compaction size are applied to a *selection* of files
> and not to individual files. It mostly works as expected only because nobody
> seems using non-default hbase.hstore.compaction.max.size, which is
> Long.MAX_VALUE and it is not that easy to figure out what is going
> on on an opposite side (why small files do not get included?)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
