[
https://issues.apache.org/jira/browse/HBASE-16454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15432510#comment-15432510
]
Hudson commented on HBASE-16454:
--------------------------------
FAILURE: Integrated in Jenkins build HBase-Trunk_matrix #1466 (See
[https://builds.apache.org/job/HBase-Trunk_matrix/1466/])
HBASE-16454 Compactor's shipping logic decision should be based on the
(ramkrishna: rev ff6182b020c0d75f8d077eaeef7ae84124e1d4ce)
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/compactions/Compactor.java
* (edit)
hbase-server/src/main/java/org/apache/hadoop/hbase/mob/DefaultMobStoreCompactor.java
> Compactor's shipping logic decision should be based on the current store's
> block size
> -------------------------------------------------------------------------------------
>
> Key: HBASE-16454
> URL: https://issues.apache.org/jira/browse/HBASE-16454
> Project: HBase
> Issue Type: Bug
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-16454.patch
>
>
> Currently we do call KeyValueScanner.shipped() if the size of the KVs
> compacted reaches certain threshold
> {code}
> if (kvs != null && bytesWrittenProgressForShippedCall >
> shippedCallSizeLimit) {
> kvs.shipped();
> bytesWrittenProgressForShippedCall = 0;
> }
> {code}
> Where the shippedCallSizeLimit is
> {code}
> long shippedCallSizeLimit = (long) minFilesToCompact *
> HConstants.DEFAULT_BLOCKSIZE;
> {code}
> Instead it is better if it is based on the actual configured block size for
> that store. It can still have the multiplying factore of 'minFilesToCompact '
> but having default store size would mean that if the store has smaller block
> sizes configured we hold on to more blocks and those will not get evicted.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
