-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/1089/
-----------------------------------------------------------
(Updated 2010-11-10 16:53:29.452432)
Review request for hbase, stack and khemani.
Changes
-------
Okay, completely scrapped my two previous implementations.
Instead, this is more of a hack but there's minimal code invasion. We persist
a file similar to .regioninfo in the regiondir called .lastmajor. It contains
a long of the last major compaction. We use it on the periodic major
compaction check and persist it when it is updated at the end of a major.
If the file does not exist (as it never will the first time a region is opened
w/ this code), it sets/persists the last major stamp as now().
Summary
-------
This is a somewhat misguided attempt. It's not done but it shows the fairly
simple change to the actual major compaction code.
The hard part is:
+ long lastMajor = region.getRegionInfo().getRegionData().getLastMajor();
And the question is where to persist that.
This patch adds a new class called HRegionData into HRegionInfo that contains
any number of key-value pairs of data that get persisted with the HRI. Not
really sure how I ended up there but this data seemed like an odd-man-out so
adding another field seemed weird. We also need some kind of versioning in HRI
so we can add stuff w/o migrating. There's some versioned stuff in HRData.
Just looking for some feedback / ideas.
This addresses bugs HBASE-2990 and HBASE-3083.
http://issues.apache.org/jira/browse/HBASE-2990
http://issues.apache.org/jira/browse/HBASE-3083
Diffs (updated)
-----
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java 1033780
trunk/src/main/java/org/apache/hadoop/hbase/regionserver/Store.java 1033780
Diff: http://review.cloudera.org/r/1089/diff
Testing
-------
Thanks,
Jonathan
