Guys, thanks a million for the help! It was a combination of a protocol version change and old client (darn -- I was only behind by a week or so!)
Goes to show how fun it is to track trunk ;-) Thanks, Roman. On Wed, Nov 2, 2011 at 3:11 PM, Stack <[email protected]> wrote: > 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 >
