本人目前做impala的二次开发，主要做java开发，impala 的使用版本是1.2.1.

       今天是年前的最后一个工作日，手头还一个bug需要修改。决定最好一天干掉这个bug.

       我们修改了impala的源码，希望它支持更多的数据库查询，修改工作完毕后，在测试中发现。 使用jdbc对一个元数据进行创建100次，然后删除100次的过程中，junit卡住不动，查后元数据看还有一部分未删除。查看日志都很正常。同时别的机器启动一个JDBC连接，也卡住无法获取连接：初步分析是锁的问题，才开始以为是数据库锁的问题，但是shell可以操作，那么只有程序中说锁的问题了。

       我主要负责java方面的开发。java使用了同步块，不存在死锁的问题。可能问题出现在c++部分。我找了开发负责人就我老大描述了下问题和分析结论。

        老大通过GDB分析死锁的问题。

        impala里面有3个进程：catalogd,impalad,statestored，因为是元数据操作，分析可能是catalogd进程的问题，因为这个进程是1.2新加的。感觉一直不太稳定。分析结果不是它的问题。然后就分析statestored。

       1：info thread:  查看所有的线程信息 ，找到wait标示的线程。

       2： t    线程号，：进入该线程

       3：bt: 打印线程栈的信息。知道是源码的哪块获取了锁。

       4：f  方法调用号： 进入获取锁的方法中。

       5：p  *this            打印锁的信息。知道有几个线程在等待锁，锁目前是哪个线程持有。

然后再分析持有锁的线程。结果发现线程1持有A锁，想获取B锁， 线程2持有B锁想获取A锁！！！

      结果真的是锁的问题，

调试bug的时候，有时候猜想也是很大的帮助。竟可能的收集信息，排除别的可能。

该bug已经在impala 1.2.3版本中进行了修改。  

下午公司同事讲statestore的架构。有机会再分享这块的东西。

还有一个问题。在测试并发的时候最还使用并发能力好的机器，因为这个问题在我的机器上不能重现，但是在测试那里却能90%重现，他使用的是刀片机。