hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matteo Bertozzi (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-15208) AsyncProcess seems to rely on regionId() to be unique which is not
Date Wed, 03 Feb 2016 00:15:39 GMT
Matteo Bertozzi created HBASE-15208:

             Summary: AsyncProcess seems to rely on regionId() to be unique which is not
                 Key: HBASE-15208
                 URL: https://issues.apache.org/jira/browse/HBASE-15208
             Project: HBase
          Issue Type: Bug
          Components: Client
    Affects Versions:, 1.1.3, 1.0.3, 2.0.0, 1.2.0, 1.3.0
            Reporter: Matteo Bertozzi

AsyncProcess is using getRegionId() to identify a region. It looks like the original implementation
was using encodedName which is unique, but then we switched to regionIds with HBASE-9988.
protected boolean canTakeOperation(HRegionLocation loc,
                                     Map<Long, Boolean> regionsIncluded,
                                     Map<ServerName, Boolean> serversIncluded) {
    long regionId = loc.getRegionInfo().getRegionId();
    Boolean regionPrevious = regionsIncluded.get(regionId);
    if (regionPrevious != null) {
      // We already know what to do with this region.
      return regionPrevious;

The RegionId is not unique, since it is a timestamp. and specifically in case we create a
table with splits each region get the same regionId. (from the doc of HRegionInfo about regionId,
looks like that field should be named creationTimestamp or something like that for a more
expressive name).

I'm unsure on what are the consequences. from a couple of tests and the code looks like it
may just allow more tasks than the one configured by the max task allowed conf. but I'd let
someone else familiar with this code look into it.

Also TestAsyncProcess has the HRegionInfo hr1, hr2, hr3 with different regionIds, if we switch
them to be the same id we have a testSubmitBusyRegionServer() failing

This message was sent by Atlassian JIRA

View raw message