今天一天服务运行正常，没有出现服务调用耗时很长和超时的情况，对于Weblogic的消息订阅，涉及到跨越信任的设置当前还没有在集成测试环境进行，同时当前JMS服务仍然是启用XA分布式事务处理状态。
而最近唯一做的调整就是我们对JndiFactory连接工厂进行了拆分，对于发消息到JMS和定义JMS消费拆分为不同的连接工厂。但是昨天咨询了Oracle技术顾问，本质的问题还是不在这里。由于观察错误日志，发现的一个奇怪现象就是在我们SendMessage到JMS中出现缓慢和超时的时候，同时也会发现业务系统订阅JMS消息出现超时和事务回滚。
也正是这个原因，我们一直认为是ERP的超时回滚影响到消息的发送。按道理对于JMS消息发送和接收本身就是一个异步的过程，同时又对连接工厂进行了拆分，即使JMS消息订阅出现问题也不应该影响到JMS消息分发。因此自己也在想是否是JMS的XA两阶段分布式事务处理，对于消息分发要一直等待消息订阅方取走消息后才算事务完成，针对这个假设进一步咨询了Oracle技术顾问，最终结论是两个完全异步，消息分发不会受到订阅接收的影响。因此唯一的可能假设就是，不管是消息分发端还是消息订阅端出现问题，本质都是JMSServer处于了一种不可用的状态，所以才导致了消息分发和接收都出现超时或回滚。
对于昨天发生的消息分发超时或长耗时问题，进一步对服务运行日志数据进行了分析，发现在上午10点左右的30分钟时间段里面，不仅仅是JMS消息分发，而是所有的WSProxy代理服务都运行缓慢，耗时长或超时。而询问了业务系统后发现是业务系统原始服务出现不可用状态，同时由于我们的连接超时时间设置是10分钟，导致大量连接等待不释放，而导致了新的服务调用无法快速的从连接池获取到可用连接，而超时报错。
也就是说JMS分发服务超时本身并不是JMS Server出现了问题，而是OSBServer本身出现了大并发无效调用占有了连接，导致响应缓慢，这种响应缓慢也直接影响到了JMS分发服务。对于昨天的情况是如此，但是在前面也时不时的发生OSB服务正常，而JMS分发缓慢的情况。因此具体还有那些影响原因暂时不清楚。
由于OSB本身集群化部署，当出现跨机器访问的时候往往耗时很长，这也是我一直怀疑的另外一个原因，就是当对JMS消息发送是Remote远程操作的时候，往往容易耗时长和超时。而对于OSB和JMS都在同一台服务器的时候却很少出现这种情况。具体是否有用跨服务器资源或跨域引起的问题还需要进一步确认。
根据最近的日志监控，对于OSB集群的性能和稳定性提出了一个新的挑战，即在大并发调用下如何确保整个集群的性能和稳定性，如何实时的监测业务系统，如果业务系统服务处于不可用状态则及时的进行处理，而不是保持大量无效长连接占用资源。这些都需要进一步进行分析和处理。