搞笑的解决ofbiz宕掉问题

公司近两年对网管产品线进行升级，新的版本采用了ofbiz框架，这玩意本身实现了一个比较完善的mvc三层架构的实现：V层推荐使用ftl或者form widget；m层提供了entity engine；c提供了service engine实现。还聚合了一些别的常见的专门话的开源项目。
这个周期也是第一个正式在客户边大规模应用的一个周期，主要是在ofbiz聚合shark的基础上实现工单流程处理，流程比较复杂，组织结构、业务分布也是比较复杂，这些都从技术上没有碰到真正麻烦的地方，一一顺利实现。
真正上线以后我们的梦魇出现了，系统是十几个小时就要僵死一次，现象是进程表现正常，log也没有提供有用的信息，除了不能登录系统，别的没有发现任何可利用的信息。更要命的是我们做了压力测试，也会僵死，但现象跟正式环境的并不一致，在测试环境下要么一直正常运行，要么是log能够报出一些内存溢出之类的东西，而且测试环境跟正式环境基本相同。
初步的判断就是内存泄露，于是用jconsole观察，发现内存并没有什么异常，虽然回收看起来没有什么规律，不过观察到线程数一直在增加，然后观察到最异常的是shark的一个tool线程；环境jvm是1.5的，os是red hat，shark用的1.1版本。此时我们的判断是线程数的异常可能引起了系统的僵死，于是将精力放在了解决这个问题上。由于最异常的一个想成是toolAgent相关的一个，这个并没有在压力测试下出现，这个也是我们考虑的一个因素。
线程数异常问题的解决过程是这个样子：在jconsole中找到最异常的线程是toolAgent相关的，于是在ofbiz里找到其实现类（为ofbiz实现的一个类，此类实现了shark的toolAgent相关接口），为多线程的，代码里没有提供有效的退出机制，就是说此线程run后永远不会退出，修改代码添加退出机制，并在各种论坛上查找类似的问题解决方案。等我们解决以后发现ofbiz的官方论坛说在某个分支版本上有人发现了这个问题并提出了解决方案，网上的方案要比我们的晚，但解决的方式要优美很多，于是升级此块代码，这块代码是独立的代码，不需要考虑其它的影响。
但头疼的是解决了线程数异常以后，正式环境系统假死现象还是存在；继续查找可能的原因，回到了原点，还是怀疑内存泄露；此时呢就兵分两路，一人在网上查找类似的问题，一人想办法得到正式环境的dump文件。
找到的一个可能的原因，我们系统用的jdbc是10g的，而db是9i的，在oracle官方论坛上提到10g的jdbc时可能会有缓存占用内存引起内存泄露的问题。于是解决，使用11的jdbc，结果是还是会有假死现象，不过时间周期确实放长了，而且还有一个意外之得，解决了我们产品线在别的地方的一个项目内存泄露问题。
另一条解决之路，想办法读取dump文件。jdk1.6下可以得到，而我们这个框架是在jdk1.5下的，于是在1.5下编译后，在1.6的环境下运行，读取dump文件。得到了大量的dump文件，但是很遗憾，没有分析出有用的结果。我们也陷入了困境。
峰回路转，系统在1.6下运行一直很稳定，搞笑的没了这个问题；也注意到有1.5在red hat下不稳定的论点，不知真伪，反正系统也就这样搞笑的暂时运行了，因为本来的计划也是要升级的1.6的。
于是搞笑的解决ofbiz宕掉问题过程结束。