J2EE疑难解决实例

2019-11-18 12:30:57

字体：大中小

来源：转载

供稿：网友

　　J2EE疑难解决实例　
　　作者：xiaoyao原创发文时间：2003.10.22
　　
　　Best Story I
　　
　　System.out.PRintln("total memory is: "
　　+ java.lang.Runtime.getRuntime().totalMemory() / 1024);
　　System.out.println("free memory is: "
　　+java.lang.Runtime.getRuntime().freeMemory() / 1024);
　　
　　有一天，一家客户要找东软麻烦，说我们的软件不好用，总死机。weblogic错误提示好象是内存分配请求失败。
　　
　　－－东软的应用系统从研发环境搬到使用环境去，一开始总要出点毛病，PC机上的tomcat终归不能跟服务器上的weblogic比啊。
　　
　　监理公司打上门来了，我和一个java天师一起受理这个案子。（java天师就是洞察java心髓的技术大师，不是精通java命令语法、熟练ide工具用法的程序员，不是编码工，以下同此义。）
　　
　　开发主力亲自过来搭建了演示环境，我们测试了一下，没有出现同等错误。操作系统是不同的unix类型，因此数据库也是不同的版本。别的地方都一样啊。
　　
　　天师用java.lang.Runtime.getRuntime().totalMemory()和freeMemory()函数得到jvm的实际分配量和使用量，发到前线去测了一下，发现虽然启动Weblogic server指定了大内存参数，实际运行时，jvm没有得到这么多内存。
　　
　　现在找到了问题，是weblogic没有打够补丁！
　　
　　案子结束，我们通知前线去索要weblogic和unix OS的最新补丁，现在该东软发飙了。
　　
　　Best Story II
　　
　　System.out.println("the caller is "
　　+ sun.reflect.Reflection.getCallerClass(0));
　　System.out.println("the caller is "
　　+sun.reflect.Reflection.getCallerClass(1));
　　System.out.println("the caller is "
　　+sun.reflect.Reflection.getCallerClass(2));
　　
　　这是我们自己的故事，NOU发布后，一切表现如常，有一次，忽然发现数据库连接池行为异常，不能正确分配新的连接。以前做压力测试、暴力测试都没有漏过一次啊？！
　　
　　为了查错，我们想知道是那些程序访问了公共的数据库访问bean。调用的地方太多，只能在bean里面加代码来实现调用者的报告了，用什么代码呢？
　　
　　我们在水母smth.org上发了一个提问，半小时内就有了一个有价值的回答，提醒我们用sun.reflect.Reflection.getCallerClass(int i)，参数随便，０，１，２，３都可以。我们试了，果然能汇报，０是getCallerClass自身，１是bean自身，２就应该是bean的调用方，３不稳定。这个函数好象不能准确的报告所有的调用层。对我们来说，能有２好用就可以了。
　　
　　我们在程序上依然没有找到错误，vaja用了一个晚上排除了代码有问题的可能性。
　　
　　最后我们把weblogic的连接池的健壮性探测开关都打开，错误排除了。
　　
　　Best Story III
　　
　　接着上一个故事，我们又调一个系统，这次是kevin的struts框架的程序搬家失败了，不能在weblogic上用。读applicationResources.properties文件失败，我们在ApplicationResources.properties文件里改了各种可能，都不行。
　　
　　我们改用struts范例，部署也不成功。
　　
　　我们换了一台服务器，范例部署成功了，而业务程序部署依然错误。
　　
　　改程序吧，kevin改了几次，没效果。
　　
　　我们能判定的是：weblogic版本对应用系统的表现有影响。
　　
　　kevin和离岛狂人一起比较了weblogic的版本，发现不能部署struts范例的系统是根本没补丁的。有补丁也是sp2。
　　
　　安装sp4？
　　
　　在大连的网管没给我们FTP权限，三天后，在沈阳，从java天师那里得到了sp4，回来装上便解决问题。
　　
　　一点经验
　　
　　调试问题，解决问题，要害在于分析，不在于编码快。
　　
　　光有j2sdk，jsp，servlet的知识和开发工具的知识，还是不够，要懂得系统运转的机理，尽量分解错误，定位错误，缩小错误范围，还可以通过各种实验来排除一些可能，形成一些有助于调试的初步结论。
　　
　　这是trouble shooting的基本思想。
　　
　　进一步，要分清楚是在研究环境还是现场环境做动作，在现场做事情另外有一些规则

上一篇：Sun在开放源代码J2EE认证上又迈出重要一步

下一篇：JNDI设计内幕