public static void waitUntilAssigned(Admin admin, RegionInfo region)
    throws IOException, InterruptedException {
    long timeout = admin.getConfiguration().getLong("hbase.hbck.assign.timeout", 120000);
    long expiration = timeout + EnvironmentEdgeManager.currentTime();
    while (EnvironmentEdgeManager.currentTime() < expiration) {
      try {
        boolean inTransition = false;
        for (RegionState rs : admin.getClusterMetrics(EnumSet.of(Option.REGIONS_IN_TRANSITION))
          .getRegionStatesInTransition()) {
          if (RegionInfo.COMPARATOR.compare(rs.getRegion(), region) == 0) {
            inTransition = true;
            break;
          }
        }
        if (!inTransition) {
          // yay! no longer RIT
          return;
        }
        // still in rit
        LOG.info("Region still in transition, waiting for " + "it to become assigned: " + region);
      } catch (IOException e) {
        LOG.warn("Exception when waiting for region to become assigned," + " retrying", e);
      }
      Thread.sleep(1000);
    }
    throw new IOException("Region " + region + " failed to move out of "
      + "transition within timeout " + timeout + "ms");
  }
In 0.90, this forces an HRI offline by setting the RegionTransitionData in ZK to have
HBCK_CODE_NAME as the server. This is a special case in the AssignmentManager that attempts an
assign call by the master. This doesn't seem to work properly in the updated version of 0.92+'s
hbck so we use assign to force the region into transition. This has the side-effect of
requiring a RegionInfo that considers regionId (timestamp) in comparators that is addressed by
HBASE-5563.
hbase-server/src/main/java/org/apache/hadoop/hbase/util/HBaseFsckRepair.java