Well spotted. It looks like we should be setting result to true if we do not NOT fall into 'f (sf.isMajorCompaction() &&....'. Please file a JIRA, and it looks like you have a patch too. Thanks for reporting this. St.Ack
On Thu, Mar 31, 2011 at 6:16 PM, Zhoushuaifeng <[email protected]> wrote: > Hi, > > I found there may be some problem with majorcompactchecker in 0.90.1: > > In the function store.isMajorCompaction: > if (filesToCompact.size() == 1) { > // Single file > StoreFile sf = filesToCompact.get(0); > long oldest = > (sf.getReader().timeRangeTracker == null) ? > Long.MIN_VALUE : > now - sf.getReader().timeRangeTracker.minimumTimestamp; > if (sf.isMajorCompaction() && > (this.ttl == HConstants.FOREVER || oldest < this.ttl)) { > if (LOG.isDebugEnabled()) { > LOG.debug("Skipping major compaction of " + this.storeNameStr + > " because one (major) compacted file only and oldestTime " + > oldest + "ms is < ttl=" + this.ttl); > } > } > } else { > When there is only one storefile in the store, and some keyvalues' TTL are > overtime, the majorcompactchecker should send this region to the compactquene > and run a majorcompact to clean these outdated data. But according to the > code in 0.90.1, it will do nothing. I think this may be a problem should be > fixed. > > > Zhou Shuaifeng(Frank) > > > ------------------------------------------------------------------------------------------------------------------------------------- > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any > use of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > >
