You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Nicolas Spiegelberg (JIRA)" <ji...@apache.org> on 2011/03/15 04:44:29 UTC

[jira] Created: (HBASE-3644) HServerAddress Violates Equivalence Relations

HServerAddress Violates Equivalence Relations
---------------------------------------------

                 Key: HBASE-3644
                 URL: https://issues.apache.org/jira/browse/HBASE-3644
             Project: HBase
          Issue Type: Bug
    Affects Versions: 0.90.2, 0.92.0
            Reporter: Nicolas Spiegelberg
            Assignee: Nicolas Spiegelberg
             Fix For: 0.90.2, 0.92.0


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

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (HBASE-3644) HServerAddress Violates Equivalence Relations

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029166#comment-13029166 ] 

stack commented on HBASE-3644:
------------------------------

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

> HServerAddress Violates Equivalence Relations
> ---------------------------------------------
>
>                 Key: HBASE-3644
>                 URL: https://issues.apache.org/jira/browse/HBASE-3644
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2, 0.92.0
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>             Fix For: 0.92.0
>
>
> 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().  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3644) HServerAddress Violates Equivalence Relations

Posted by "Nicolas Spiegelberg (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006799#comment-13006799 ] 

Nicolas Spiegelberg commented on HBASE-3644:
--------------------------------------------

I think, for 0.90, it should suffice to just remove 
{code}
    result ^= stringValue.hashCode();
{code}
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?

> HServerAddress Violates Equivalence Relations
> ---------------------------------------------
>
>                 Key: HBASE-3644
>                 URL: https://issues.apache.org/jira/browse/HBASE-3644
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2, 0.92.0
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>             Fix For: 0.90.2, 0.92.0
>
>
> 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().  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3644) HServerAddress Violates Equivalence Relations

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006798#comment-13006798 ] 

stack commented on HBASE-3644:
------------------------------

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.

> HServerAddress Violates Equivalence Relations
> ---------------------------------------------
>
>                 Key: HBASE-3644
>                 URL: https://issues.apache.org/jira/browse/HBASE-3644
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2, 0.92.0
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>             Fix For: 0.90.2, 0.92.0
>
>
> 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().  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3644) HServerAddress Violates Equivalence Relations

Posted by "Nicolas Spiegelberg (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006803#comment-13006803 ] 

Nicolas Spiegelberg commented on HBASE-3644:
--------------------------------------------

@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?

> HServerAddress Violates Equivalence Relations
> ---------------------------------------------
>
>                 Key: HBASE-3644
>                 URL: https://issues.apache.org/jira/browse/HBASE-3644
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2, 0.92.0
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>             Fix For: 0.90.2, 0.92.0
>
>
> 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().  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (HBASE-3644) HServerAddress Violates Equivalence Relations

Posted by "stack (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/HBASE-3644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007076#comment-13007076 ] 

stack commented on HBASE-3644:
------------------------------

@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.

> HServerAddress Violates Equivalence Relations
> ---------------------------------------------
>
>                 Key: HBASE-3644
>                 URL: https://issues.apache.org/jira/browse/HBASE-3644
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.90.2, 0.92.0
>            Reporter: Nicolas Spiegelberg
>            Assignee: Nicolas Spiegelberg
>             Fix For: 0.90.2, 0.92.0
>
>
> 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().  

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira