hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Running preliminary testing on HBase 0.92/Hadoop 0.22
Date Wed, 02 Nov 2011 22:11:01 GMT
On Wed, Nov 2, 2011 at 12:38 PM, Ted Yu <yuzhihong@gmail.com> wrote:
>> On Wed, Nov 2, 2011 at 12:22 PM, Roman Shaposhnik <rvs@apache.org> wrote:
>>
>>> On Wed, Nov 2, 2011 at 10:42 AM, Stack <stack@duboce.net> wrote:
>>> > In HBaseClient, its here:
>>> >
>>> >      if (remoteId.getAddress().isUnresolved()) {
>>> >        throw new UnknownHostException("unknown host: " +
>>> >
>>> remoteId.getAddress().getHostName());
>>> >      }
>>> >
>>> >
>>> > getAddress is an InetSocketAddress..... and javadoc for isUnresolved:
>>> >
>>> >  "....true if the hostname couldn't be resolved into an InetAddress."
>>> >
>>> > Its kinda baffling Roman especially if other clients -- shell -- can
>>> > get to master fine.
>>>
>>> Got that. Now, here's the odd part. When I connect to the VM with
>>> a debugger and dump the value of
>>>     remoteId.address.hostname
>>> here's what I get:
>>>     "\u0000\u0000ip-10-118-254-245.ec2.internal"
>>>
>>> That, of course, explains why such an address can't be resolved,
>>> but do you guys have any idea what could put those \u0000\u0000
>>> in front of the actual hostname?
>>>

hbase-4300 added versioning to the ServerName that is stored up in zk.
 Version is a short on the front of the name.  The 'first' VERSION is
0.  Looking in MasterAddressTracker in 0.92, I see it doing this when
you call masterAddressTracker#getMasterAddress (in HConnectionManager
inside getMaster): ServerName.parseVersionedServerName(bytes);  This
should be stripping those version bytes off the front of the name.
You are up-to-date Roman?

St.Ack

Mime
View raw message