HBase
  1. HBase
  2. HBASE-3644

HServerAddress Violates Equivalence Relations

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Invalid
    • Affects Version/s: 0.90.2, 0.92.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      See HBASE-3387 or http://www.ibm.com/developerworks/java/library/j-jtp05273.html#N10184 . Basically, 'a' denotes HServerAddress(DNS) & 'b' denotes HServerAddress(nslookup(DNS)). This is extremely common within HBase when 'conf/regionserver' contains DNS entries because ClusterStatus.getServers() is IP-based. You have a.address.equals(b.address) && !a.stringValue.equals(b.stringValue). In this case, a.equals(b) while a.hashCode() != b.hashCode().

        Issue Links

          Activity

          stack made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Invalid [ 6 ]
          Hide
          stack added a comment -

          No HSA anymore. Resolving as no longer valid.

          Show
          stack added a comment - No HSA anymore. Resolving as no longer valid.
          stack made changes -
          Fix Version/s 0.92.0 [ 12314223 ]
          Hide
          stack added a comment -

          Moving out of 0.92.0. Pull it back in if you think different.

          Show
          stack added a comment - Moving out of 0.92.0. Pull it back in if you think different.
          Hide
          stack added a comment -

          hbase-1502 has been committed and in includes deprecation of hsa

          Show
          stack added a comment - hbase-1502 has been committed and in includes deprecation of hsa
          stack made changes -
          Fix Version/s 0.90.2 [ 12316152 ]
          Hide
          stack added a comment -

          @N 1502 deprecates it. I'm back on that now. Hopefully something to go in in the next week or so. Meantime if you want to remove stringValue, thats fine. When I come through with hbase-1502, I can do fixup.

          Show
          stack added a comment - @N 1502 deprecates it. I'm back on that now. Hopefully something to go in in the next week or so. Meantime if you want to remove stringValue, thats fine. When I come through with hbase-1502, I can do fixup.
          Hide
          Nicolas Spiegelberg added a comment -

          @Stack: hmm. I was using HSA because it was in the existing HBCK code that I'm improving. I think I might be able to move over to pure ISA. Should we add @Deprecated annotations to this class?

          Show
          Nicolas Spiegelberg added a comment - @Stack: hmm. I was using HSA because it was in the existing HBCK code that I'm improving. I think I might be able to move over to pure ISA. Should we add @Deprecated annotations to this class?
          Hide
          Nicolas Spiegelberg added a comment -

          I think, for 0.90, it should suffice to just remove

              result ^= stringValue.hashCode();
          

          Even if a.stringValue != b.stringValue, it's okay for a.hashCode() == b.hashCode() && !a.equals(b), just can't have the other way around. This wouldn't solve the case where stringValue matches but address doesn't, however that's not the common case and I'm pretty sure that's not possible anymore because of HBASE-2806.

          However, it seems like the stringValue is sort of unnecessary and can be removed in 0.92. Because of checkBindAddressCanBeResolved() from HBASE-2806, you're guaranteed that the hostname will always be resolved when working with an HServerAddress. Because of HBASE-3286, we use address.getHostName() to generate stringValue anyways. It seems like stringValue is just a legacy variable that can be removed. JD, Stack, or any other people who worked on this class, am I missing something?

          Show
          Nicolas Spiegelberg added a comment - I think, for 0.90, it should suffice to just remove result ^= stringValue.hashCode(); Even if a.stringValue != b.stringValue, it's okay for a.hashCode() == b.hashCode() && !a.equals(b), just can't have the other way around. This wouldn't solve the case where stringValue matches but address doesn't, however that's not the common case and I'm pretty sure that's not possible anymore because of HBASE-2806 . However, it seems like the stringValue is sort of unnecessary and can be removed in 0.92. Because of checkBindAddressCanBeResolved() from HBASE-2806 , you're guaranteed that the hostname will always be resolved when working with an HServerAddress. Because of HBASE-3286 , we use address.getHostName() to generate stringValue anyways. It seems like stringValue is just a legacy variable that can be removed. JD, Stack, or any other people who worked on this class, am I missing something?
          Hide
          stack added a comment -

          Does it help that HBASE-1502 is trying to strip out HServerAddress N? Its adding in a new ServerName instead, a carrier for the String hostname, the int port, and the long startcode. No DNS in the mix. HBASE-1502 is about removing heartbeats but along the way deprecating HSA and HServerInfo.

          Show
          stack added a comment - Does it help that HBASE-1502 is trying to strip out HServerAddress N? Its adding in a new ServerName instead, a carrier for the String hostname, the int port, and the long startcode. No DNS in the mix. HBASE-1502 is about removing heartbeats but along the way deprecating HSA and HServerInfo.
          Nicolas Spiegelberg made changes -
          Field Original Value New Value
          Link This issue relates to HBASE-3387 [ HBASE-3387 ]
          Nicolas Spiegelberg created issue -

            People

            • Assignee:
              Nicolas Spiegelberg
              Reporter:
              Nicolas Spiegelberg
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development