ejb
和ejb相关的内容，包括weblogic
摘要: 当时实际上，我们在检查ThreadDeath的调用信息时，说明这个出现init()错误的filter还是被glassfish正常调用去执行doFilter()方法，这里和j2ee API的要求是不符合的。有点奇怪的是，glassfish一向是以严格遵循j2ee规范而著称，居然在这里一反常态。
而更令人 郁闷的是，glassfish在处理这个有filter初始化出现ServletException异常的webapp时的前后表现：首先这个 webapp的启动没有问题，状态正常。filter也被认为可以正常工作并加入了filter链。webapp中的功能正常，可以正常的接收请求并转发给内容业务处理模块。从这些迹象看这个webapp基本没有问题。但是后面glassfish却莫名其妙的认定，“this web application instance has been stopped already”，从而以ThreadDeath这种非常规的error来报错。
阅读全文
摘要: 在application server下，比如常见的weblogic，glassfish，jboss等，由于javaee规范的要求，一般不容许直接启动线程。因此在常见的异步/并行任务执行上，会遭遇到比普通javase程序更多的麻烦。
阅读全文
摘要: 近期由于公司有意向在未来将目前的一个大型产品从weblogic移植到glassfish，因此提前学习glassfish以做好准备。
首先从下载安装开发，学习如何搭建glassfish的开发环境。
阅读全文
摘要: 问题终于找到，简单的说是因为java 系列化的效率低下，而ejb调用之间又大量使用系列化，因此造成极大的性能消耗，而且也影响到响应时间。仔细分析了一下项目情况，呵呵，情况非常严重，系统架构是按照三层来设计的，每个层都是ejb，调下一层都是通过远程接口，而且层之间可能还多个ejb的调用。
总结一下：
1. java serialize 非常慢
2. enable-call-by-reference可以有效避免这个开销
因此，能enable-call-by-reference就尽量enable-call-by-reference。
阅读全文
摘要: 接上篇，有兴趣的朋友可以直接拿我的测试代码自行测试,请自行修改诸如线程数，执行时间，系列化的数据量大小等参数。如果想尝试做thread dump，可以打开相关的两个注释，会更方便一些，代码中都有相应的注释可供参考。
阅读全文
摘要: 这是加入新公司后接手的第一个项目，使用weblogic9.2 + ejb2.0，压力测试时发现速度非常慢，响应时间很不理想，检查日志发现，某些ejb相互调用时方法调用的时间非常长，高达300-500毫秒。非常夸张，因为两个日志之间只是间隔了一个ejb调用。通过thread dump分析后发现有相当多的线程在wait，检查线程调用绽发现是在将参数进行序列化时，线程试图加锁但是锁被占用，因此处于等待状态。考虑到 thread dump的这一瞬间，有多达30-50个线程都在同时试图在同一个锁上加锁，很明显这里的锁竞争非常严重。
因此强烈怀疑是java的序列化机制导致的问题。
阅读全文