[jira] Commented: (HBASE-3644) HServerAddress Violates Equivalence Relations
[ 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
[
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
[ 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
[ 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
[jira] [Commented] (HBASE-3644) HServerAddress Violates Equivalence Relations
[ 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
