转载

技术问题分析13(6.13)

今天记录几个关键问题的跟踪和分析情况。首先说下JMS服务的分发长延迟问题，这个问题在前面我们做了调整后基本没有再出现，即调用WS服务，将消息发送到JMS Topic主题里面基本正常。但是我们在启用了JMS Server的Cluster集群和故障漂移后，发现偶尔会出现发送长延时的问题。

同时在日志里面发现：

BEA-002939

The maximum thread constraint ClusterMessaging has been reached 2 times for the last seconds

简单来看就是最大线程约束数一直在超过最大值，同时观察Server本身的活动线程数也经常很大，虽然只有少量消费服务在调用，但是线程数多的时候可以达到200的数值。对于这个问题查了下Oracle官方的资料，反馈是属于提示类告警信息，可以不用理会。但是整体感觉还是不正常，同时从ClusterMessaging提示信息也可以看到，和我们启用了Cluster集群和故障漂移有关系。在我们关闭掉集群和故障漂移后，再观察Log日志，发现已经没有上门的这个告警日志，同时活动线程数完全降低下来，一般在50以内，同时再进行JMS服务分发测试的时候基本都响应很快，没有再发现服务分发长耗时的场景。

对于该问题具体原因暂时不清楚，看来还需要进一步和Oracle顾问分析和确认。

对于JMS订阅端订阅消息延迟的问题

对于JMS订阅端的订阅消息延迟，前面已经讲过了，业务系统会出现事务超时回滚的错误，该错误还在进一步分析中，原来分析的原因主要集中在两个方面，一个是涉及到跨越安全信任方面的问题，一个是涉及到启用XA分布式事务处理后，相关的设置有问题导致。具体原因还在进一步分析中。

但是最近出现其它的原来正常的业务系统也出现获取订阅消息延迟较长的问题，对于这点专门上网搜索了下相关的资料，发现队列和主题，在高级设置里面都有一个MessagingPerformancePreference选项，该选项主要是设置对于JMS消息是否是批量进行分发，可以设置0到100之间的不同值。如果设置为0那么就是不启用批处理，只要有消息就进行分发。

而对于这个值，在Topic主题里面是设置的无须等待，对消息进行批处理。这个默认值，而这个默认值本身的值是25，也就是说消息要累计到25条的时候才会进行一次发送。那么在消息分发不频繁的时候，一定就会造成订阅方在获取消息的时候延迟比较大。

经过初步分析，我认为是和这个参数的设置有关系，需要进一步在测试环境进行验证后确认。

对于JMS订阅端代码的问题

今天进行JMS Log日志监控，发现对于Topic主题的订阅，经常在日志里面看到反复进行ConsumerCreate消费者的创建操作。按道理这个是不合理的。即最好的方式就是创建好连接，Session和Consumer后，该消费者就一直对Topic主题进行监听操作，发现有新的消息就取走。而不是需要不断的重新去创建Consumer，同时对于Consumer不断重复创建本身也是一个耗时的操作。

对于JMS消息订阅，务必要注意的还是OnMessage方法的实现只应该是获取消息，存储到本地文件或者插入到数据库的接口临时表里面就及时反馈。而对于获取到消息本身的数据完整性和入库到正式表则应该分开由另外一个任务进行处理，只有这样才能够保证消息的快速接收和处理。否则将很容易引起消息接收超时。

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

正文到此结束