AOP@Work: 用AspectJ进行性能监视,第2部分 - 编程入门网
"."+thisJoinPointStaticPart.getSignature().getName();
key = key.intern();
return lookupResourceStats (key);
}
};
return requestContext.execute();
}
}
AOP@Work: 用AspectJ进行性能监视,第2部分(8)时间:2011-09-07 IBM Ron Bodkin注意,只需要做很少的工作就可以支持这种功能,大多数支持包含在 AbstractRequestMonitor 中。我只是定义远程代理调用为对任何实现了 Remote 接口的公共方法的调用,这个方法可以抛出 RemoteException。完成这个小小的 改变后,就可以使用 Worker Object 模式(请参阅 第 1 部分)监视远程调用 , 提供一个以类名和被调用的对象的方法名为基础的名字。RemoteCallMonitor 方 面使用一个 helper 方法寻找顶级资源统计,它是从 JdbcConnectionMonitor 中 的工人对象中提取的,放入这个新的公共基本方面:AbstractResourceMonitor 。 自然,可以进一步扩展这种方法以监视其他 Web 服务调用以及流行框架(如 Apache Axis)上方法的执行。我还可以使用这种技术监视 XML 处理所花费的时 间,这对于任何有大量 XML 的应用程序是很有用的。许多利用 Web 服务的应用 程序也可受益于这种监视。 监视故障 合乎逻辑的下一步是扩展 Glassbox Inspector 系统以监视应用程序故障。 我 首先在系统退出一个监视点时通过抛出一个异常(更准确地说是任何 Throwable )来记录故障。故障记录为跟踪 Web 操作和数据库连接工作提供了有用的信息 : 这些操作中的任何一个抛出 Throwable 在几乎任何情况下都表示有问题。对于 JDBC 语句和其他资源访问,throwable 通常表明一个真正的应用程序故障,但 是 在有些情况下,它是正常程序逻辑的一部分。例如,试图用一个已经有的名字注 册会在插入时触发异常。为了照顾到这种情况,我对每个监视使用了一个可配置 的策略,以确定给定的 throwable 是真正的错误还是作为正常的退出条件接受 。 清单 7 包含了使我可以配置 AbstractRequestMonitor 以确定 Throwable 是 否为故障的建议和改动: 清单 7. 增加可扩展的故障检测
清单 7 中最后的效果是,在通过抛出异常退出一个监视的连接点时记录一个 计数。注意,我肯定是要识别那些通过抛出 Error 退出的情况,因为它们几乎 肯 定是故障!在这里,可以容易地扩展这个 AbstractRequestMonitor 以跟踪部分 或者所有异常、堆栈踪迹和在发生异常时 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务,公司网站:http://www.lingzhong.cn 为了给广大客户了解更多的技术信息,本技术文章收集来源于网络,凌众科技尊重文章作者的版权,如果有涉及你的版权有必要删除你的文章,请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息,谢谢! |