Class RegionStateNode

java.lang.Object
org.apache.hadoop.hbase.master.assignment.RegionStateNode
All Implemented Interfaces:
Comparable<RegionStateNode>

@Private public class RegionStateNode extends Object implements Comparable<RegionStateNode>
Current Region State. Most fields are synchronized with meta region, i.e, we will update meta immediately after we modify this RegionStateNode, and usually under the lock. The only exception is lastHost, which should not be used for critical condition.

Typically, the only way to modify this class is through TransitRegionStateProcedure, and we will record the TRSP along with this RegionStateNode to make sure that there could at most one TRSP. For other operations, such as SCP, we will first get the lock, and then try to schedule a TRSP. If there is already one, then the solution will be different:

  • For SCP, we will update the region state in meta to tell the TRSP to retry.
  • For DisableTableProcedure, as we have the xlock, we can make sure that the TRSP has not been executed yet, so just unset it and attach a new one. The original one will quit immediately when executing.
  • For split/merge, we will fail immediately as there is no actual operations yet so no harm.
  • For EnableTableProcedure/TruncateTableProcedure, we can make sure that there will be no TRSP attached with the RSNs.
  • For other procedures, you'd better use ReopenTableRegionsProcedure. The RTRP will take care of lots of corner cases when reopening regions.

Several fields are declared with volatile, which means you are free to get it without lock, but usually you should not use these fields without locking for critical condition, as it will be easily to introduce inconsistency. For example, you are free to dump the status and show it on web without locking, but if you want to change the state of the RegionStateNode by checking the current state, you'd better have the lock...