ActiveMQ 消息接收事件每秒只有一条消息？
我们已经构建了基于ActiveMQ的应用程序基础架构。
我们可以很好地发送和接收消息，而且大多数情况下一切都非常快且正常。
然而，我们注意到，如果我们“一次”提交一批消息，比如 5,000 条消息，ActiveMQ 会很快地将消息发送到另一端的第 3 方应用程序，并且该应用程序也会很快处理，并且它也会快速将回复排队返回经纪人，比如说一分钟之内。
但由于某种原因，我们最初发出消息的 VB.NET EXE 似乎只是不稳定地处理它收到的返回消息，有时大约每秒处理一次，有时会休息一个小时左右，然后返回到每秒一个。
Origin (VB.NET EXE which we manage)
-> Broker (which we manage)
-> (3rd party app)
-> back to the same broker
-> back to the origin app.
接收器正在等待来自 ActiveMQ 大约 9 个月前下载的 C# 代码的事件 MessageListener：
Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
Member of: NMS
我认为发生的情况是 MessageListener 只给我们一条消息 (NMS.IMessage) 供我们咀嚼，所以这就是我们处理的内容。
有没有什么方法可以说“在 MessageListener 事件中，请查看队列中是否还有其他消息，然后全部执行”？
We've built up an application infrastructure based on ActiveMQ.
We can send and receive messages just fine, and for the most part things are pretty fast and OK.
However, we've noticed that if we submit a batch of messages "at once", say 5,000 messages - that ActiveMQ will get the messages to the 3rd party application on the other end pretty quickly, and that this application will process also pretty quickly, and that it will en queue the replies back to the broker quickly also, say under a minute.
But for some reason, our VB.NET EXE that originated the messages in the first place only appears to be processing the return messages it receives erratically, sometimes doing about one per second, sometimes taking breaks for an hour or so and then going back to one per second.
Origin (VB.NET EXE which we manage)
-> Broker (which we manage)
-> (3rd party app)
-> back to the same broker
-> back to the origin app.
The Receiver is waiting for the event MessageListener from C# code downloaded from ActiveMQ maybe 9 months ago:
Public Delegate Sub MessageListener(ByVal message As NMS.IMessage)
Member of: NMS
I think what's happening is that MessageListener only gives us one message (NMS.IMessage) to chew on, and so that's what we process.
Is there some way to say "On a MessageListener event, please see if there are other messages on the queue right now and do them all"?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实证明，我们认为我们现在更了解这是什么意思了。
当我们使用 ActiveMQ DLL 的 VB.NET WinForms 应用程序最终崩溃时（这种情况每周都会发生几次），我们有一个看门狗程序，它使用 Winternals pslist 和 pskill 实用程序来捕获僵尸，然后启动一个新客户端联系。
发生这种情况时，使用 jconsole 分析代理表明僵尸会话仍然注册，新客户端也是如此。
我现在的理论是，当 AMQ 看到两个会话时，它会尝试开始以循环方式向两个会话分发消息。 AMQ 尝试将消息发送给僵尸，但僵尸没有响应。 经过一定时间（也许一秒）AMQ 放弃并转到列表中的下一个会话，即新的客户端。
在某些时候，代理或 TCP 堆栈可能会注意到僵尸没有保持其 TCP 连接处于活动状态并放弃； 然后操作恢复正常。
所以问题就变成了，如何编写一个 ActiveMQ 客户端，a) 不会死掉，或者 b) 优雅地死掉，并在此过程中关闭它的会话？
编辑：升级到 ActiveMQ 的下一个版本解决了这个问题。 此外，我们有一个应用程序执行发送和接收，但它不是线程安全的 - 因此，如果它在尝试发送时接收，则会导致崩溃。 我们将其重写为两个控制台应用程序，一个发送数据，另一个接收数据。 不再发生崩溃。 此外，我们当时使用的旧版本 ActiveMQ 无法很好地处理崩溃，升级到 4.x 解决了这个问题。
Turns out, we think we know a bit more now what this is about.
When our VB.NET WinForms app that uses the ActiveMQ DLL eventually crashes, which it tends to do a few times a week, we have a watchdog program that uses the Winternals pslist and pskill utilities to reap the zombie, and then start a new client connection.
When this happens, using jconsole to analyze the broker shows us that the zombie's session is still registered, and so is the fresh new client.
My theory right now is that when AMQ sees both sessions, it tries to start distributing messages to both sessions round-robin style. AMQ tries to send the message to the zombie, which does not respond. After a certain amount of time (one second perhaps) AMQ gives up and goes to the next session in the list, the new fresh client.
At some point, the broker or TCP stack probably notices that the zombie has not kept it's TCP connection active and it gives up; then operation goes back to normal.
So the question becomes, how to write an ActiveMQ client that a) does not die or b) dies gracefully, shutting down it's session in the process?
Edit: upgrading to the next version of ActiveMQ solved this. Also we had a single app doing the sending and receiving, but it was not threadsafe - so if it received while it was trying to send this caused the crashes. We re-wrote it as two console apps, one that sent data and one that received data. No more crashes. Also the older version of ActiveMQ we were using at the time didn't handle crashes gracefully, upgrading to 4.x solved that.
我建议将此问题报告给用户论坛，并可能提出< a href="http://activemq.apache.org/camel/support.html" rel="nofollow noreferrer">支持问题 因为这听起来可能是 NMS 客户端代码和所有NMS 开发人员在该列表中并且可能会做出回应
I'd suggest reporting this to the User Forum along with maybe raising a support issue as this sounds like it could be some issue with the NMS client code and all the NMS developers are on that list and might respond