1，一开始都是调用HttpMethod的getResponseBody()和getResponseBodyAsString，但这样总会出现下图中的警告信息
String response = null;
BufferedReader resBufferReader = null;
try {
httpClient.executeMethod(httpMethod);
resStream = httpMethod.getResponseBodyAsStream();
resBufferReader = new BufferedReader(new InputStreamReader(resStream));
StringBuffer resBuffer = new StringBuffer();
String resTemp = "";
while((resTemp = resBufferReader.readLine()) != null){
resBuffer.append(resTemp);
}
response = resBuffer.toString();
} catch (Exception e) {
}
public static HBaseAdmin hBaseAdmin = null;
public static void init() {
hBaseConfiguration = HBaseConfiguration.create();
try {
hBaseAdmin = new HBaseAdmin(hBaseConfiguration);
} catch (Exception e) {
throw new HbaseRuntimeException(e);
}
}
这里其实是将两个默认的配置文件加进来了，对于相同的配置项，后者会覆盖前者
conf.addResource("hbase-site.xml");
可是总是报下面的错：
Caused by: java.io.IOException: Unable to determine ZooKeeper ensemble
断点跟踪到Zookeeper的源码发现是ZKUtil类的connect方法抛出的异常，
Watcher watcher, final String descriptor)
throws IOException {
if(ensemble == null) {
throw new IOException("Unable to determine ZooKeeper ensemble");
}
int timeout = conf.getInt("zookeeper.session.timeout", 180 * 1000);
LOG.debug(descriptor + " opening connection to ZooKeeper with ensemble (" +
ensemble + ")");
return new ZooKeeper(ensemble, timeout, watcher);
}
上述代码表明是没有读取到Zookeeper集群的地址，这个地址是在ZooKeeperWatcher的构造函数中读取的：
继续跟下去，发现配置信息是makeZKProps方法读取出来的，
// it and grab its configuration properties.
ClassLoader cl = HQuorumPeer. class.getClassLoader();
final InputStream inputStream =
cl.getResourceAsStream(HConstants.ZOOKEEPER_CONFIG_NAME);
if (inputStream != null) {
try {
return parseZooCfg(conf, inputStream);
} catch (IOException e) {
LOG.warn("Cannot read " + HConstants.ZOOKEEPER_CONFIG_NAME +
", loading from XML files", e);
}
}
看到这里才恍然大悟，它会首先去检查CLASSPATH下是否有zoo.cfg文件，如果有，则将其中的配置项读取出来作为Zookeeper的配置项，而此时就会完全不顾 hbase-default.xml和hbase-site.xml这两个配置文件了！
3， Zookeeper有两个异常需要特别认真地去考虑，
1）第一种情况是连接丢失，在丢失的这段时间，你的操作是不生效的，也就意味着你所做的delete,setData,makePath这些操作都是无效的，这就是第一个要特别去处理的异常信息
KeeperException.ConnectionLossException，处理的方法很简单，就是引入重试机制，指定好最大重试次数，重试间隔时间即可。
KeeperException exception = null;
for ( int i = 0; i < retryCount; i++) {
try {
return (T) operation.execute();
} catch (KeeperException.ConnectionLossException e) {
if (exception == null) {
exception = e;
}
if (Thread.currentThread().isInterrupted()) {
Thread.currentThread().interrupt();
throw new InterruptedException();
}
retryDelay(i);
}
}
throw exception;
}
2）第二种情况是Session的超时。当你第一次连接Zookeeper时，是可以注册一个Watcher的，这个Watcher的作用就是应对Zookeeper连接成功和会话超时的，
当后者发生时，你必须进行尝试重新连接Zookeeper服务器的动作，一旦重新连接成功，你就可以做一些应用层的初始化动作，这里是通过onReconnect.command()来实现的，OnReconnect接口是一个钩子，用于重连完成时，回调进行一些初始化动作的。
if (log.isInfoEnabled()) {
log.info("Watcher " + this + " name:" + name + " got event " + event + " path:" + event.getPath() + " type:" + event.getType());
}
state = event.getState();
if (state == KeeperState.SyncConnected) {
connected = true;
clientConnected.countDown();
} else if (state == KeeperState.Expired) {
connected = false;
log.info("Attempting to reconnect to recover relationship with ZooKeeper...");
// 尝试重新连接zk服务器
try {
connectionStrategy.reconnect(zkServerAddress, zkClientTimeout, this,
new ZkClientConnectionStrategy.ZkUpdate() {
@Override
public void update(SolrZooKeeper keeper) throws InterruptedException, TimeoutException, IOException {
synchronized (connectionStrategy) {
waitForConnected(SolrZkClient.DEFAULT_CLIENT_CONNECT_TIMEOUT);
client.updateKeeper(keeper);
if (onReconnect != null) {
onReconnect.command();
}
synchronized (ConnectionManager. this) {
ConnectionManager. this.connected = true;
}
}
}
});
} catch (Exception e) {
SolrException.log(log, "", e);
}
log.info("Connected:" + connected);
} else if (state == KeeperState.Disconnected) {
connected = false;
} else {
connected = false;
}
notifyAll();
}
4，今天在做solr的master/slave切换时遇到一个让人困扰的问题
场景描述：
3个solr节点的集群，1个master节点，名为m1,2个slave节点，分别为s1,s2,每个solr节点都在Zookeeper集群中同一个Znode下注册为EPHEMERAL_SEQUENTIAL节点，分别可以得到一个序号，采取“序号最小者为master”的策略来进行master选举。若m1节点挂掉，则下一个序号最小的slave节点自动接替成为新的master，假定此slave是s1,则此时有3件事要完成:
1) s1节点上的solr核的solrConfig.xml配置文件中有关replication的片段，必须从slave的配置改成master的配置，并且reload其对应的solr核
2)其他slave节点（这里是s2)必须修改其配置文件中有关replication的片段，将原先指向m1的masterUrl改为指向s1，并且reload其对应的solr核
3）若原先挂掉的m1节点重新回到集群中来，则它会在上面提到的那个Znode下重新一个EPHEMERAL_SEQUENTIAL节点，并且序号肯定会比s1,s2的大，则m1会发现已经有新的master节点s1存在，自动识别出自己的身份是slave，其上的solr核也会采用有关slave的配置片段，并且指向s1所在的新的masterUrl
问题：
我现在碰到的情况是，s1将其配置文件从slave改为master，然后reload的结果是，索引目录文件由index变成了index.时间戳，导致s2这个slave节点在从s1复制索引时却是默认从index这个目录去复制的，从而无法找到索引文件，s1上的indexversion返回是0.
目前卡在这个地方，明天来好好研究下真实原因。。。