我放弃了JBoss社区论坛 - 永远不会回答那里的问题。所以试试这里。
我已经编写了一个小测试程序来帮助我诊断我在实时环境中看到的问题，但是我对JBoss MQ的无数可配置设置感到困惑，甚至更加困惑的是他们有所作为。
环境是JBoss 4.0。，4。
在实时环境中，远程计算机上从独立Java应用程序到JBoss MQ主题（由MDB提供服务）的JMS连接正在丢失。我没有任何关于它为什么会丢失的信息（以及异常监听者的参与）。
所以我创建了一个带有Java应用程序的测试环境，该应用程序将TextMessages（包含递增的数字）发送到远程JBoss上的Topic。
MDB代码所做的只是在TextMessage中打印数字。
我注意到的第一件事是打印的线程称为“JMS SessionPool Worker-XX”，其中XX为0到32。 当我再次运行发送方应用程序时，XX的值为32到46.第三次运行时，值为46到60.模式总是相同的 - 在JBoss启动后第一次运行时使用的线程更多，14或后续运行中的15个线程。
所以，问题1：该模式是否有解释？
在运行期间，它发送大约15,000条消息，jms_messages表在JBoss机器上构建。这意味着JBoss MQ无法跟上，对吧？我假设内存必须超过mysql-jdbc2-service.xml中MessageCache MBean定义中指定的阈值。但是当我监视JVM内存时，它远远没有为HighMemoryMark指定的150MB值。我想我误解了围绕MessadeCache bean定义的这个评论：“一旦JVM内存使用率达到高内存标记，缓存中的旧消息将开始存储在DataDirectory中”。我认为这意味着当堆使用量达到150MB时，收到的消息将开始写入jms_messages，但显然我错了。
问题2：JBoss MQ开始写入jms_messages的情况是什么？
最后一个问题 - 下面的容器配置设置是否与我处理消息的线程数有关？
<container-pool-conf>
<MaximumSize>500</MaximumSize>
<container-pool-conf>
谢谢。
答案 0 :(得分：1)
自从我需要使用JBoss MQ以来已经很长时间了...所以它不是你（有趣的）问题的真正答案，但无论如何都可能有所帮助。
如果您使用内置的HSQL数据库作为JBoss MQ的消息存储，那么您无法处理短时间内发送的15k消息等负载。你需要切换到一个真正的数据库，除非你想放弃持久的消息存储（据我记得你可以配置它），这对性能有好处，但有些消息可能永远丢失。
JBoss MQ并不是有史以来最好的JMS提供者。事实上，它不是生产就绪的解决方案，并且使用它是一个真正的痛苦（没有好的文档，奇怪的配置，你现在正在经历的）。这就是为什么JBoss人员将JBoss 5.X切换到JBoss Messaging（事实上在商业JBoss 4.X EAP中 - 而不是GA - 他们总是使用JBoss Messaging）。
对switch to HornetQ来说，不是最好的选择 - 它有很好的文档记录，强大且可以处理非常大的负载。