IBM MQ 消息限制
我们正在使用 IBM MQ，并且在控制其异步传递到接收者方面面临一些严重的问题。我们配置了一些 java 侦听器，现在的问题是我们需要控制传入侦听器的消息，因为传入服务器的消息数量以百万计，而服务器机器没有那么多容量可以一次处理这么多线程，那么有没有什么方法可以像 IBM MQ 端的节流一样，我们可以像 Apache MQ 那样配置预蚀刻限制？
或者还有其他方法可以实现这一目标吗？
目前，当侦听器达到某些 X 限制时，我们正在关闭与 IBM MQ 的连接，但这似乎不是有效的方法。
请大家帮助我们解决这个问题。
We are using IBM MQ and we are facing some serious problems regarding controlling its asynchronous delivery to its recipient.We are having some java listeners configured, now the problem is that we need to control the messages coming towards listener, because the messages coming to server are in millions count and server machine dont have that much capacity t process so many threads at a time, so is there any way like throttling on IBM MQ side where we can configure preetch limit like Apache MQ does?
or is there any other way to achieve this?
Currently we are closing connection with IBM MQ when some X limit has reached on listener, but doesen't seems to be efficient way.
Please guys help us out to solve this issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
通常，对于 MQ 等消息队列技术，队列的要点是发送方与接收方解耦。如果您在消息量方面遇到问题，那么答案是让它们在接收方队列中排队并尽可能地处理它们，而不是限制发送方。
显而易见的答案是限制侦听器允许占用的最大线程数。我假设您正在使用某种 MQ 线程池？您使用什么平台提供无限的侦听器线程？
根据您的描述，听起来您似乎正在运行某个进程 - 一旦它检测到队列中的消息 - 它就会读取该消息，启动一个新线程，然后返回并再次查看队列。这是错误的做法。
您应该运行定义数量的进程线程（从一个开始，然后根据需要扩展，并在服务器的限制内），这些线程从队列本身读取。如果您收到 MQRC 2033（队列中没有消息），它们将各自以共享模式打开队列，并且要么 get-with-wait，要么立即进行睡眠获取。
希望有帮助。
Generally with message queueing technologies like MQ the point of the queue is that the sender is decoupled from the receiver. If you're having trouble with message volumes then the answer is to let them queue up on the receiver queue and process them as best you can, not to throttle the sender.
The obvious answer is to limit the maximum number of threads that your listeners are allowed to take up. I'm assuming you're using some sort of MQ threadpool? What platform are you using that provides unlimited listener threads?
From your description, it almost sounds like you have some process running that - as soon as it detects a message in the queue - it reads the message, starts up a new thread and goes back and looks at the queue again. This is the WRONG approach.
You should have a defined number of process threads running (start with one and scale up as required, and within limits of your server) which read from the queue themselves. They would each open the queue in shared mode and either get-with-wait or do immediate get with a sleep if you get a MQRC 2033 (no messages in queue).
Hope that helps.
如果您在应用程序服务器环境中运行，则activationSpec 上的maxPoolDepth 属性将定义MDB 的最大ServerSessionPool 大小 - 减少此值将限制同时传送的消息数量。
当然，如果您的 MDB（或 JSE 环境中的 javax.jms.MessageListener）什么都不做，只是将消息传递给其他东西（或者更糟糕的是，只是生成一个非托管线程并启动它），onMessage 将快速旋转，您仍然会遇到问题。因此，在这种情况下，您还需要限制其他资源，例如通过线程池配置。
关闭与 QM 的连接从来都不是一种有效的方法，因为 MQCONN/MQDISC 周期的成本很高。
If you are running in the application server environment, then the maxPoolDepth property on the activationSpec will define the maximum ServerSessionPool size for the MDB - decreasing this will throttle the number messages being delivered concurrently.
Of course, if your MDB (or javax.jms.MessageListener in the JSE environment) does nothing but hand the message to something else (or, worse, just spawn an unmanaged Thread and start it) onMessage will spin rapidly and you can still encounter problems. So in that case you need to limit other resources too, e.g. via threadpool configuration.
Closing the connection to the QM is never an efficient way, as the MQCONN/MQDISC cycle is expensive.