0

我们正在使用 IBM MQ，并且在控制其向接收者的异步传递方面遇到了一些严重的问题。我们配置了一些 java 侦听器，现在的问题是我们需要控制到达侦听器的消息，因为到达服务器的消息以百万计，服务器机器没有那么多容量一次处理这么多线程，那么有没有办法像在 IBM MQ 端进行节流一样，我们可以像 Apache MQ 那样配置 preetch 限制？

还是有其他方法可以实现这一目标？

目前，当侦听器达到某个 X 限制时，我们正在关闭与 IBM MQ 的连接，但这似乎不是一种有效的方式。

请大家帮我们解决这个问题。

4

2 回答 2

5

通常对于像 MQ 这样的消息队列技术，队列的重点是发送者与接收者分离。如果您在消息量方面遇到问题，那么答案是让它们在接收者队列中排队并尽可能地处理它们，而不是限制发送者。

显而易见的答案是限制您的侦听器允许占用的最大线程数。我假设您正在使用某种 MQ 线程池？您使用什么平台提供无限的侦听器线程？

根据您的描述，听起来您几乎有一些进程正在运行 - 一旦它检测到队列中的消息 - 它就会读取消息，启动一个新线程并返回并再次查看队列。这是错误的方法。

您应该有一个定义数量的进程线程正在运行（从一个开始并根据需要进行扩展，并且在您的服务器的限制范围内），这些线程从队列本身中读取。如果您获得 MQRC 2033（队列中没有消息），他们每个人都会以共享模式打开队列，要么等待获取，要么立即获取睡眠。

希望有帮助。

于 2011-07-19T06:57:42.673 回答
0

如果您在应用程序服务器环境中运行，则 activationSpec 上的 maxPoolDepth 属性将定义 MDB 的最大 ServerSessionPool 大小 - 减小这将限制同时传递的消息数量。

当然，如果您的 MDB（或 JSE 环境中的 javax.jms.MessageListener）什么都不做，只是将消息交给其他东西（或者，更糟糕的是，只是生成一个非托管线程并启动它），onMessage 将快速旋转，您仍然会遇到问题。因此，在这种情况下，您还需要限制其他资源，例如通过线程池配置。

关闭与 QM 的连接从来都不是一种有效的方法，因为 MQCONN/MQDISC 周期很昂贵。

于 2011-07-19T08:39:27.100 回答