You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Gary Helmling (JIRA)" <ji...@apache.org> on 2011/04/12 21:40:07 UTC

[jira] [Created] (HBASE-3772) Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS

Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS
---------------------------------------------------------------------------------------------------------------------------------------

                 Key: HBASE-3772
                 URL: https://issues.apache.org/jira/browse/HBASE-3772
             Project: HBase
          Issue Type: Bug
            Reporter: Gary Helmling


I ran across this issue on a 0.20 based branch, so I'm not sure if this is still an issue for 0.90+.  However, 0.90 and current trunk do still make use of DNS.getDefaultHost(), so I wanted to open this for discussion.

In 0.20, the problem was:

 1. configure hbase-site.xml with hbase.regionserver.dns.interface=xxx
 2. IP bound on interface xxx has reverse DNS correctly configured
 3. DNS.getDefaultHost() calls DNS.reverseDns() for this IP, which does a JNDI bind to the DNS provider, returning the *absolute* hostname: host1.my.domain.
 4. RS reports startup to master as host1.my.domain.,60020,1234...
 5. BaseScanner when scanning .META. sees region assignments as not valid because the resolved hostname from IP goes through InetSocketAddress.getHostName() which returns the canonicalized form (host1.my.domain != host1.my.domain. though they are equivalent)

I know the master <-> RS negotiated hostname has completely changed for 0.90.  So hopefully this is no longer an issue and we can close as invalid and go have a beer.  But given the underlying problem in DNS.getDefaultHost(), I wanted to confirm this.

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

[jira] [Commented] (HBASE-3772) Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS

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

stack commented on HBASE-3772:
------------------------------

I haven't seen it.  I've just seen issues where HSA resolves differently on either side of the connection whether one side finds FQDN and the other only a hostname or other side is failing reverse DNS and so just uses IP.  hbase-1502 is going to deprecated HSA and just pass Strings rather than have an HSA do resolve on deserialization (ISA creation).

> Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3772
>                 URL: https://issues.apache.org/jira/browse/HBASE-3772
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Gary Helmling
>
> I ran across this issue on a 0.20 based branch, so I'm not sure if this is still an issue for 0.90+.  However, 0.90 and current trunk do still make use of DNS.getDefaultHost(), so I wanted to open this for discussion.
> In 0.20, the problem was:
>  1. configure hbase-site.xml with hbase.regionserver.dns.interface=xxx
>  2. IP bound on interface xxx has reverse DNS correctly configured
>  3. DNS.getDefaultHost() calls DNS.reverseDns() for this IP, which does a JNDI bind to the DNS provider, returning the *absolute* hostname: host1.my.domain.
>  4. RS reports startup to master as host1.my.domain.,60020,1234...
>  5. BaseScanner when scanning .META. sees region assignments as not valid because the resolved hostname from IP goes through InetSocketAddress.getHostName() which returns the canonicalized form (host1.my.domain != host1.my.domain. though they are equivalent)
> I know the master <-> RS negotiated hostname has completely changed for 0.90.  So hopefully this is no longer an issue and we can close as invalid and go have a beer.  But given the underlying problem in DNS.getDefaultHost(), I wanted to confirm this.

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

[jira] [Commented] (HBASE-3772) Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS

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

Gary Helmling commented on HBASE-3772:
--------------------------------------

Looking further at HMaster and HRegionServer, both launder the returned hostname through HServerAddress, which uses InetSocketAddress to resolve the hostname.  So I believe we will *not* see this issue in 0.90/trunk.  Anyone want to confirm?

> Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3772
>                 URL: https://issues.apache.org/jira/browse/HBASE-3772
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Gary Helmling
>
> I ran across this issue on a 0.20 based branch, so I'm not sure if this is still an issue for 0.90+.  However, 0.90 and current trunk do still make use of DNS.getDefaultHost(), so I wanted to open this for discussion.
> In 0.20, the problem was:
>  1. configure hbase-site.xml with hbase.regionserver.dns.interface=xxx
>  2. IP bound on interface xxx has reverse DNS correctly configured
>  3. DNS.getDefaultHost() calls DNS.reverseDns() for this IP, which does a JNDI bind to the DNS provider, returning the *absolute* hostname: host1.my.domain.
>  4. RS reports startup to master as host1.my.domain.,60020,1234...
>  5. BaseScanner when scanning .META. sees region assignments as not valid because the resolved hostname from IP goes through InetSocketAddress.getHostName() which returns the canonicalized form (host1.my.domain != host1.my.domain. though they are equivalent)
> I know the master <-> RS negotiated hostname has completely changed for 0.90.  So hopefully this is no longer an issue and we can close as invalid and go have a beer.  But given the underlying problem in DNS.getDefaultHost(), I wanted to confirm this.

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

[jira] [Resolved] (HBASE-3772) Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS

Posted by "stack (Resolved) (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/HBASE-3772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stack resolved HBASE-3772.
--------------------------

    Resolution: Cannot Reproduce

Resolving 'cannot reproduce'.  I don't think we have this issue anymore.  We can open new issue if we run into it again.
                
> Hadoop DNS.reverseDns() doesn't canonicalize host names, leading to possible discrepancy in RS hostname vs. Master seen hostname for RS
> ---------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-3772
>                 URL: https://issues.apache.org/jira/browse/HBASE-3772
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Gary Helmling
>
> I ran across this issue on a 0.20 based branch, so I'm not sure if this is still an issue for 0.90+.  However, 0.90 and current trunk do still make use of DNS.getDefaultHost(), so I wanted to open this for discussion.
> In 0.20, the problem was:
>  1. configure hbase-site.xml with hbase.regionserver.dns.interface=xxx
>  2. IP bound on interface xxx has reverse DNS correctly configured
>  3. DNS.getDefaultHost() calls DNS.reverseDns() for this IP, which does a JNDI bind to the DNS provider, returning the *absolute* hostname: host1.my.domain.
>  4. RS reports startup to master as host1.my.domain.,60020,1234...
>  5. BaseScanner when scanning .META. sees region assignments as not valid because the resolved hostname from IP goes through InetSocketAddress.getHostName() which returns the canonicalized form (host1.my.domain != host1.my.domain. though they are equivalent)
> I know the master <-> RS negotiated hostname has completely changed for 0.90.  So hopefully this is no longer an issue and we can close as invalid and go have a beer.  But given the underlying problem in DNS.getDefaultHost(), I wanted to confirm this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira