hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Gray" <jg...@apache.org>
Subject Re: Review Request: Fix periodic major compaction (HBASE-2990) and expiration check (HBASE-3083)
Date Thu, 11 Nov 2010 00:53:29 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated 2010-11-10 16:53:29.452432)

Review request for hbase, stack and khemani.


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().


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.

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




View raw message