On Wed, Nov 2, 2011 at 12:38 PM, Ted Yu <[email protected]> wrote: >> On Wed, Nov 2, 2011 at 12:22 PM, Roman Shaposhnik <[email protected]> wrote: >> >>> On Wed, Nov 2, 2011 at 10:42 AM, Stack <[email protected]> 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
