问题描述
在下列情况中可怀疑出现服务器挂起：

•  服务器不响应新的请求。
•  请求超时。
•  请求处理的时间越来越长（其最终结果可能是挂起）。
•  通常，服务器挂起不会表现为服务器崩溃，但服务器挂起之后可能会崩溃。

故障排除
常规服务器挂起模式说明了在针对 EJB_RMI 服务器挂起模式采取任何具体措施之前应当采取的诊断步骤。

快速链接

• 为什么发生此问题？
• 基本步骤
• Thread Dump 分析
• 解决方法

为什么发生此问题？
由于对在群集状态下如何存储群集对象以及如何从 Weblogic JNDI 树检索群集对象缺乏了解导致不合理设计，是发生这个问题的原因。错误理解还会给应用程序体系结构实现造成不必要的网络通信。不必要网络通信引起的后果是线程等待对未完成的 rmi/rjvm 请求的响应。这些请求是在集群域中进行远程 JNDI 查找的结果。

返回页首

基本步骤
确保已经完成在“常规服务器挂起模式”中介绍的所有步骤。在似乎已挂起的服务器实例上大约每隔 3 秒完成的一系列（3 到 5 个）Thread Dump。

返回页首

Thread Dump 分析
与 EJB_RMI 服务器挂起关联的线程有下文说明的典型模式。如果 Thread Dump 中的许多“Default”队列线程有相同的调用堆栈模式，那么挂起问题就很可能与使用某个对象的远程 JNDI 查找有关。

在此线程的堆栈跟踪中，您马上就可以发现一些端倪。由于此线程在某个 wait 方法中，因此它在等待发生某种情况，例如将要收到的工作或数据。因为它等待来自 weblogic.rjvm.ResponseImpl.waitForData()方法中的远程 JVM 的数据，所以调用此 wait()方法。如果堆栈中的许多线程都等待来自其它群集成员的数据，那么这些群集成员也可能等待来自此 JVM 的数据。

at weblogic.rjvm.ResponseImpl.waitForData(ResponseImpl.java:72)

继续跟踪调用堆栈，查明在 waitForData之前执行什么操作。从此堆栈中可以判断，一个 servlet 正在执行 JNDI 查找。

weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341

jndi 对象的查找被发送到远程 JVM。此线程堆栈显示它已经决定从全局 JNDI 树执行查找。

at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:80

从什么地方获取 InitialContext是根据在应用程序代码中派生 InitialContext 的方式决定的。若要从全局 JNDI 树中查找对象，需要有用于获取 InitialContext 的环境属性。其中一个属性 providerURL决定在哪一个群集成员上获取 InitialContent并随后执行查找。如果没有提供任何属性，则对 getInitialContext()的调用使用 WebLogic Server 实例的当前环境。在下面的线程堆栈中，指定的 providerURL不是该群集成员实例。因此，此线程堆栈显示通过 sendReceive()方法对远程 jvm 发出的调用。

"ExecuteThread: '52' for queue: 'default'" daemon prio=5 tid=0x4b3e40b0 nid=0x1170 waiting on monitor [0x4c74f000..0x4c74fdbc] at java.lang.Object.wait(Native Method) at weblogic.rjvm.ResponseImpl.waitForData(ResponseImpl.java:72) at weblogic.rjvm.ResponseImpl.getTxContext(ResponseImpl.java:97) at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:80) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:262) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy6.lookup(Unknown Source) at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341) at weblogic.servlet.internal.HttpServer.lookupROIDS(HttpServer.java:789) at weblogic.servlet.security.internal.SecurityModule.getCurrentUser(SecurityModule.java:207) at weblogic.servlet.security.internal.SecurityModule.checkAuthenticate(SecurityModule.java:235) at weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.java:271 at weblogic.servlet.security.internal.ServletSecurityManager.checkAccess(ServletSecurityManager.java:124) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2518) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

总结起来，Thread Dump 显示许多“Default”队列线程都在等待对某个 rmi 请求的响应。在每个 rmi 请求之前，调用 weblogic.jndi.internal.WLContextImpl.lookup()。该调用指明应用程序代码正在尝试执行 JNDI 查找。堆栈跟踪上的下一组调用显示该查找是一个远程查找。注意 BasicOutboundRequest.sendReceive()和 subsequent waitForData()。

返回页首

解决方法
在一个群集中，所有同构部署的服务都在该群集的全局 JNDI 中。该群集的所有成员都用相同的对象引用。从本地 JNDI 树和全局树中都可以获得相同的对象引用信息。

检查 getInitialContext()调用的代码。如果设置了环境属性（特别是 PROVIDER_URL），则强制执行远程查找。更改此代码以便执行本地 JNDI 查找。

返回页首

是否需要更多帮助？

如果您已经理解这个模式，但仍需要其它帮助，您可以：

1. 在 http://support.bea.com 上查询 AskBEA（例如，使用“EJB RMI server hang”），以查找其它已发布的解决方案。
2. 在 http://support.bea.com 上，向 BEA 的某个新闻组中提出更详细具体的问题。

如果这还不能解决您的问题，并且您拥有有效的技术支持合同，您可以通过登录以下网站来打开支持案例：http://support.bea.com。

返回页首