Hi James, I noticed the same thing and thus mentioned the server having 2 ethernets. No I do not have any hbase or hadoop configuration in my classpath. Any ideas what might be causing the problem?
Regards, Imran On Oct 7, 2010 2:06 PM, "James Baldassari" <[email protected]> wrote: Hi Imran, Glad that fixed your XML parsing problem. I haven't used HBaseTestingUtility (we start up a test cluster by extending HBaseClusterTestCase), but I did notice something that looked strange in your logs. You can see that the namenode binds to 127.0.0.1:37523, and ZK also uses 127.0.0.1, but then you see this: 10/10/06 20:53:14 INFO net.NetworkTopology: Adding a new node: /default-rack/223.27.113.138:48680 10/10/06 20:53:14 INFO datanode.DataNode: New storage id DS-517982013-127.0.1.1-48680-1286430794780 is assigned to data-node 223.27.113.138:48680 It looks like the datanode is binding to 223.27.113.138 instead of 127.0.0.1. Then further down: 10/10/06 20:53:15 INFO hdfs.StateChange: BLOCK* NameSystem.allocateBlock: /user/hudson/hbase.version. blk_6520143473758843527_1001 10/10/06 20:53:15 INFO hdfs.DFSClient: Exception in createBlockOutputStream java.net.ConnectException: Connection refused 10/10/06 20:53:15 INFO hdfs.DFSClient: Abandoning block blk_6520143473758843527_1001 10/10/06 20:53:15 INFO hdfs.DFSClient: Excluding datanode 223.27.113.138:48680 10/10/06 20:53:15 WARN namenode.FSNamesystem: Not able to place enough replicas, still in need of 1 When my unit test cluster starts up everything binds to 127.0.0.1. I'm not sure if that's your problem, but it definitely looks like the DFS client can't talk to the datanode for some reason. Maybe someone who is more familiar with HBaseTestingUtility will know what could cause this. Do you have hbase-default.xml and/or hbase-site.xml on your test classpath? If so, what do they contain? -James On Thu, Oct 7, 2010 at 1:59 AM, Imran M Yousuf <[email protected]> wrote: > Just an update - > >...
