轻量服务器_总裁爹地宠上天百度云_评分榜

小七 2019年10月25日 21:23 141 0

在sappo单java栈系统中，我们至少有以下控制消息处理线程数的选项：

集群节点数；连接定义system.queueParallelism.perInterface接口接管人MessagePrioritization

让我们用下面的故事情节来详细说明以上所有选项的功能。

A公司有一个SAP PO系统，它是一个java堆栈，有一个咆哮的场景。

PO使用JMS发送者通道从JMS队列Q1检索订单消息，并通过REST将订单消息推送到系统Target01的API接收器通道。

PO服务器有一个集群节点，所有配置都是默认的。

它工作得很好。

有一天，一个新的类似场景需要建立如下。

而消息从上游系统掉到JMS队列Q2的速度有点快。问题是

即使JMS发送队列（JMS）最多有5个线程_HTTP//SAP/COM/XI/XI/StReS送)已经使用，Q2还有一些积压

考虑到安装的系统SAP PO有足够的CPU数量和足够的内存，为了解决以上问题，增加了集群节点数量从1到2（SAP KBA#1734360）。

由于从JMS队列中提取消息的最大线程数增加了一倍，我们有足够的工人从队列中提取消息，现在系统工作正常。

A公司的业务不断增长。第一季度和第二季度的订单信息越来越多。接收Ack所花费的时间。（通常是HTTP状态）从Target01的角度看，比从Q1和Q2检索消息的JMS发送方通道长一点。渐渐地，它会导致调度器队列中的大量积压。

症状是消息监视器中的许多消息处于"待传递"状态，并且需要很长时间才能传递消息。

另一方面，Target01表示，尽管接收一条消息需要很长时间，但系统已经容量大，可同时接受多个来电

因此我们可以增加消息传递.连接定义

解决方案

NWA–>配置–>基础设施–>Java服务属性

选项卡服务–>XPI服务：AF核心–>消息传递.连接定义

在本物业内，我们可以配置适配器特定队列的数量。默认数目是每个群集节点5个。现在我们把它增加到20。将以下字符串添加到属性并重新启动J2EE服务。

（name=JMS_HTTP//SAP/COM/XI/XI/S系统，点云，messageListener=localejbs/AFWListener，exceptionListener=localejbs/AFWListener，pollInterval=60000，pollAttempts=60，Send.maxConsumers=20, Recv.maxConsumers=5个, Call.maxConsumers=5, Rqst.maxConsumers=5个)

由于我们现在有两个集群节点，我们现在使用JMS发送方通道的所有场景最多有40个线程。

配置更改后，在dispatcher队列中有更多的线程接收消息。尽管Target01端的消息处理时间有点慢，但由于线程较多（JMS发送队列），调度队列中的积压已经被扫除了

随着a公司业务的发展，添加了一个新的场景，如下所示。

添加了一个新的队列来接收新的主数据（来自上游系统），SAP PO将数据同步到Target02。由于单个主数据的大小非常巨大，完成一个调用需要很长时间，比如说每次调用需要1分钟。

虽然系统中有3个场景，但很快我们就会发现40个线程都被场景3用完了。对于场景1和场景2，Target01比Target02快得多，但是没有分配空线程（队列）来处理它们的消息。这两个场景完成一个过程仍然需要很长时间。他们的大多数消息都再次处于"待传递"状态。

解决方案

NWA–>配置–>基础设施–>Java服务属性

选项卡服务–>XPI服务：消息传递系统–>

system.queueParallelism.perInterface接口system.queueParallelism.maxReceivers=系统.queueParallelism.maxReceivers

要让机制工作，请将property perInterface从默认值false设置为true。然后将属性maxReceivers的值设置为10。这意味着一旦配置，每个集群节点每个接口的最大线程数（适配器特定队列）是10个

记住重新启动J2EE服务

重新启动服务后，我们可以看到场景3最多占用了10*2=20个线程。由于场景1和场景2整个PO系统还有20个线程，大数据可视化，所以这两个场景不会有太多的积压