Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo, mail # user - Getting the IP Address


Copy link to this message
-
Re: Getting the IP Address
John Vines 2013-08-28, 21:56
But that code is for getting an address of an external host, is it not?
Will it guarantee that it won't return localhost if it's attempting to
resolve itself?
On Wed, Aug 28, 2013 at 5:01 PM, Ravi Mutyala <[EMAIL PROTECTED]> wrote:

> I think for HDFS, scripts just send the hostname and the ip is resolved in
> org.apache.hadoop.net.NetUtils
>
> Below code takes the host and gets the address.
>
> public static InetSocketAddress createSocketAddrForHost(String host, int
> port) {
>     String staticHost = getStaticResolution(host);
>     String resolveHost = (staticHost != null) ? staticHost : host;
>
>     InetSocketAddress addr;
>     try {
>       InetAddress iaddr = SecurityUtil.getByName(resolveHost);
>       // if there is a static entry for the host, make the returned
>       // address look like the original given host
>       if (staticHost != null) {
>         iaddr = InetAddress.getByAddress(host, iaddr.getAddress());
>       }
>       addr = new InetSocketAddress(iaddr, port);
>     } catch (UnknownHostException e) {
>       addr = InetSocketAddress.createUnresolved(host, port);
>     }
>     return addr;
>   }
>
>
> I tried with DNS or/etc/hosts set on RHEL and they are resolving the
> correct IP address. I tried a similar sample code on mac and that was
> working too. I think hadoop assumes either DNS or /etc/hosts to be set. I
> think it would be a fair assumption to make for accumulo as well.
>
> Thoughts?
>
>
>
> On Wed, Aug 28, 2013 at 3:44 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:
>
>> Seems like a question a common and complex as which IP address to listen
>> on would have a fair amount of precedent in open-source projects that we
>> could pull from. Are we reinventing the wheel? Does anyone have an example
>> of an application like ours with the same set of supported platforms that
>> has already solved this problem and whose solution you like? Are there
>> elements of what we do that make us better/worse/different that something
>> like the scripting and networking code built for HBase or HDFS?
>>
>> Adam
>>
>>
>>
>> On Wed, Aug 28, 2013 at 1:35 PM, Keith Turner <[EMAIL PROTECTED]> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Aug 28, 2013 at 4:26 PM, Christopher <[EMAIL PROTECTED]>wrote:
>>>
>>>> Ah, you're right, of course.
>>>>
>>>> In that case, I'm also wondering about NAT situations and other
>>>> strange networking situations. For those especially, it seems what we
>>>> need to do is treat the bind address differently from the advertised
>>>> address.
>>>>
>>>> Perhaps attempting to use $(hostname -i) and falling back to
>>>> $(hostname -I | head -1) would be best?
>>>>
>>>
>>> I just noticed one wrinkle with "hostname -I",  it may return IPV6
>>> addresses.   When I first looked at the man page, I thought it would
>>> exclude IPV6.  But on closes inspection I noticed it excludes "IPv6
>>> link-local addresses".  So hostname -I will probably cause problems if the
>>> first thing it returns is a IPV6 addr.
>>>
>>>
>>>>
>>>> --
>>>> Christopher L Tubbs II
>>>> http://gravatar.com/ctubbsii
>>>>
>>>>
>>>> On Wed, Aug 28, 2013 at 3:03 PM, John Vines <[EMAIL PROTECTED]> wrote:
>>>> > Christopher,
>>>> >
>>>> > It's not a matter of determining which port to bind to. It's for
>>>> recording
>>>> > it's location in zookeeper so other nodes can find it.
>>>> >
>>>> >
>>>> > On Wed, Aug 28, 2013 at 3:00 PM, Christopher <[EMAIL PROTECTED]>
>>>> wrote:
>>>> >>
>>>> >> I'm not sure this is even very portable. It relies on a specific
>>>> >> ifconfig display format intended for human-readability, and I'm not
>>>> >> sure that's entirely guaranteed to be static over time. It also won't
>>>> >> work if there are multiple public interfaces. It also don't think it
>>>> >> works for infiniband or other interface types that have issues in
>>>> >> ifconfig.
>>>> >>
>>>> >> I think we have to make *some* assumptions that things like
>>>> >> "networking" is properly configured using standard utilities for
>>>> >> name-mapping (like DNS or /etc/hosts). I think it's more confusing