NIO异常新动向2

关于NIO这个异常报错，《         hadoop和hive结合使用总结（关于一个稳定性的问题）         》博客里的几种方式，都不是很长久，差不多1-2天的时间就会出现问题了。

在尝试过几种方式后，最终我采用了一种我认为很不好的一种方式但很简单，解决方式如下：

在Client类里的sendParam方法增加了一段代码：

out.flush();

try {

    Thread.sleep(100);

    if (LOG.isDebugEnabled())

        LOG.debug("have reset 100 mill");

} catch (InterruptedException e) {

}

就是在发送完请求后，暂停100毫秒（也许可以再继续降低暂停的时间，不过我测试过暂停10毫秒，但没有成功过。其他时间都没有测试了）。

注意此修改只是影响到hive与namenode、jobtasker的交互频率。

这样就不会再此出现被中断的情况了。但是此方式有诸多不好，最明显的就是延长了hive一个脚本的运行时间（不过目前应用还不是很多，暂时能用这种方式抵挡一阵子，长远来看还是不好的）。

为了彻底弄清楚这个原因最近考虑了很多问题后，重新整理了思路又绕回了起点，来分析：

java.nio.channels.ClosedByInterruptException这个异常如何产生。

其实该异常的产生在JDK的文档里已经有了说明：

Checked exception received by a thread when another thread interrupts it while it is blocked in an I/O operation upon a channel. Before this exception is thrown the channel will have been closed and the interrupt status of the previously-blocked thread will have been set.

至于为什么会导致这样的问题出现的这么频繁，最近又分析了下hive源码，暂时还没有发现是哪个线程中断了这个正在写IO通道的线程。

hive本地命令调用的方法（Driver类里的execute()方法里，当开启并行模式后，就是下面这段代码发起）代码部分截取如下：

while (runnable.peek() !=null && running.size() <maxthreads) {

          Task<? extends Serializable> tsk = runnable.remove();

          launchTask(tsk, queryId, noName, running, jobname, jobs, driverCxt);

}

目前通过初步的判断应该不是代码所为（如果代码有问题的话，那么datanode与namenode的交互早应该有这样的情况出现了。），可能与操作系统有关联吧。

对于这个问题的分析将继续研究下去，接下来考虑采用hive service方式，然后hive与namenode分离到两台机器上，然后再看看是否有这样的情况。

采用hive的service模式后还是有这样的报错信息(不管在同台机器上还是分开在两台机器上面)。