每日学习笔记（24）

1，一开始都是调用HttpMethod的getResponseBody()和getResponseBodyAsString，但这样总会出现下图中的警告信息





这是由于没有使用缓存的缘故，如果字符串数据过多，会出警告，应该改用流和缓存来读取数据：

InputStream resStream = null;
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) {
}

2， 连接Zookeeper的方法如下：

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-default.xml");
conf.addResource("hbase-site.xml");

可是总是报下面的错：

An error is preventing HBase from connecting to ZooKeeper

Caused by: java.io.IOException: Unable to determine ZooKeeper ensemble

断点跟踪到Zookeeper的源码发现是ZKUtil类的connect方法抛出的异常，

public static ZooKeeper connect(Configuration conf, String ensemble,
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的构造函数中读取的：

this.quorum = ZKConfig.getZKQuorumServersString(conf);

继续跟下去，发现配置信息是makeZKProps方法读取出来的，

// First check if there is a zoo.cfg in the CLASSPATH. If so, simply read
// 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，处理的方法很简单，就是引入重试机制，指定好最大重试次数，重试间隔时间即可。

public <T> T retryOperation(ZkOperation operation) throws KeeperException, InterruptedException {
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接口是一个钩子，用于重连完成时，回调进行一些初始化动作的。

public synchronized void process(WatchedEvent event) {
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.

目前卡在这个地方，明天来好好研究下真实原因。。。