转载

技术问题分析06(4.21)

首先回顾下4.18日分析的内容，即关键入口异常和问题还是HTTP 500错误。

[Deployer:149150]An IOException occurred while reading the input. : with response code '500' : with response message 'Internal Server Error'

一直没有找到确切的原因，对于Oracle Support网站提到的权限不足的原因以及进行尝试没有解决问题。同时怀疑是Cluster集群间状态同步出现问题，对其它集群节点全部进行暂停处理，但是仍然会存在这个问题。对于部署本身的500错误，同时导致Session无法正常关闭，即这个时候如果我们再去部署就很容易导致Session被占用的情况。特别是针对同一个Project项目去部署。

而实际我们看到通过JMX进行服务部署的时候，异常也是发生在activateSession这个方法操作上面，即Session无法激活，要么是500错误，要么是Session被占用。同时在发送500错误的时候Session又没有办法释放掉。

首先说下进行的新的尝试，即我们在部署的时候将所有的OSB Server节点全部停止掉，只保留Admin节点和管控Server，然后通过管控JMX接口方式进行部署，结果完全正常没有任何问题，在部署完成后再将OSB服务器启动，Cluster会进行自动同步，没有出现任何问题。而这个现象跟网上的有篇问题类似：

https://community.oracle.com/thread/2496665

但是网上的这篇文章现在也没有一个正确的解决方案和回答。只是说明了有人遇到过类似的场景和问题。

其次我们怀疑是否是OSB在进行服务部署的时候，如果这个服务正在被调用和消费，会导致相应的Session占有而部署不成功。为了验证这个假设，我们在开发环境又进行了相关的验证，结果发现开发环境部署也完全正常，OSB本身服务的是否在调用不影响到OSB服务的热部署过程。

考虑到将OSB节点停用后，可以正常部署，那么说明还是在部署的时候程序部署到Admin上面后，但是Admin朝Cluster集群中的OSB集群节点进行AutoDeploy和状态同步分发的时候出现的错误。为了验证这个说法，又将实际的OSB，Admin和Domain日志进行进一步的分析和梳理。具体如下：

1. 首先是前台的异常捕获能够查询到异常日志，具体为：

[Deployer:149150]An IOException occurred while reading the input. : with response code '500' : with response message 'Internal Server Error'

java.rmi.RemoteException: [Deployer:149150]An IOException occurred while reading the input. : with response code '500' : with response message 'Internal Server Error'

at weblogic.utils.StackTraceDisabled.unknownMethod()

2. 其次，我们转到Admin Server的Log日志，发现同样的问题

第一段：[OSB-390100] Session import1523799234174 is being activated

第二段：[OSB-390101] An IOException occurred while reading the input. : with response code '500' : with response message 'Internal Server Error' at weblogic.deploy.service.internal.transport.http.HTTPMessageSender.sendMessageToServerURL(HTTPMessag

可以看到首先是激活会话动作启动，但是最终激活Session会话失败，报错为500错误。而正常的日志则是在[OSB-390100]之后是[OSB-390102]，Session会话激活成功。这也是我们在前面解决该问题的时候做了大量的关键字搜索的地方，但是搜索出的文章和解决方法仍然没有彻底解决该问题。

3. 在查看了Admin Log后我们再查看Domain的日志信息。

第一段信息： java.rmi.UnknownHostException: Could not discover administration URL for server 'osb_server9_1'

第二段信息：

而这里第一段信息的时间和Admin日志的第一段时间匹配，而第二段时间和Admin的第二段时间匹配。由于在这里我们看到了SocketTimeoutException的30秒超时，所以我们后面对Weblogic Admin上的Http Post几个超时时间进行了重新设置到120秒，但是仍然没有彻底解决问题。

这个时候我们基本有了很明显的概念，即整个异常过程的导致如下：

在管控台进行服务的部署的时候，首先服务部署到Admin Server上，然后对部署包进行会话激活，但是在激活会话的时候需要Admin将服务部署包的内容同步到各个OSB Server节点上面去。但是这个在朝OSB Server节点进行同步的时候发现Could not discover administration URL，这个时候处于一直等待状态，如果在30秒也无法找到OSB Server节点，那么就出现TimeOut的异常，而这个异常转移到Admin Server上面，形成了新的异常，即前面说的HTTP 500的内部异常。

即整个问题的关键还是集群上面出了问题，具体什么问题还需要进一步诊断。

4. 在出现了这个异常后，我们再进行重新部署，由于HTTP 500异常的Catch处理无法通过DiscardSession正常的释放会话信息，因此就导致了后面写的Session占有的一系列其它异常。

到此整个问题和逻辑基本全部梳理清楚，最终需要查的问题点在为何Could not discover administration URL这个问题上面，如果这个问题解决了，那么最终问题应该解决。

基于这个假设，我们再到Oracle知识库根据关键字

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=528992417343858&id=2339592.1&displayIndex=2&_afrWindowMode=0&_adf.ctrl-state=pch3wo1vn_409#CAUSE

该问题导致原因为：

Synchronization problem between managed servers.

When a cluster synchronization problem occurs, the managed servers cannot send properly the monitoring statistics to the Aggregation Manager, which runs in the cluster primary server. This will lead to the aggregation errors and checkpoint warnings.

具体的解决方案如下：

*** Important: Perform a backup of the environment.

1) Shutdown the Admin and Oracle Service Bus Managed servers in the domain cluster.

2) For all the servers shut down, delete the files and folders under the following directories:

$FMW_HOME/user_projects/domains//servers//cache

$FMW_HOME/user_projects/domains//servers//stage

$FMW_HOME/user_projects/domains//servers//tmp

3) Rename the Oracle Service Bus configuration path for the managed server: mv /osb/config/core_ /osb/config/core_.old

4) Restart the servers.

该解决方案需要进一步验证以确认问题是否解决掉。

原文 http://blog.sina.com.cn/s/blog_493a84550102xcmy.html

正文到此结束