Centos 6.8 大黄蜂2.3.25SP10 Jboss 6.4
java -version Java版本“ 1.7.0_151” OpenJDK运行时环境（rhel-2.6.11.0.el6_9-x86_64 u151-b00）
uname -a：
2.6.32-696.16.1.el6.x86_64＃1 SMP周三11月15日16:51:15 UTC 2017 x86_64 x86_64 x86_64 GNU / Linux
我们有4个Jboss节点，其配置如下所示
64 GB的RAM 8个CPU内核
我们正在以集群模式使用4个Jboss服务器。我们的产品是一个网络管理平台，我们将在其中管理和配置设备。设备的状态更改将通过JMS消息（HornetQ）进行通信。
我们的一个客户环境包含19k台设备。
当我们尝试在主题中发布状态通知时，它会以延迟的方式被接收到订阅者。当我们说延迟时，它大约在3到4小时到1-2天之间。这正在影响我们客户的环境，他们目前处于紧急状态才能解决此问题。
请告诉我们此版本的hornetQ是否存在任何已知问题，以及如何解决此问题。 我们可以在服务器中配置任何调优参数来提高HornetQ的性能。
HornetQ设置如下
<hornetq-server> <clustered>true</clustered> <persistence-enabled>true</persistence-enabled> <cluster-password>newClusterPassword</cluster-password> <jmx-management-enabled>true</jmx-management-enabled> <transaction-timeout>60000000</transaction-timeout> <journal-type>ASYNCIO</journal-type> <journal-min-files>2</journal-min-files> <connectors> <netty-connector name="netty" socket-binding="messaging"/> <netty-connector name="netty-throughput" socket-binding="messaging-throughput"> <param key="batch-delay" value="50"/> </netty-connector> <in-vm-connector name="in-vm" server-id="0"/> </connectors> <acceptors> <netty-acceptor name="netty" socket-binding="messaging"/> <netty-acceptor name="netty-throughput" socket-binding="messaging-throughput"> <param key="batch-delay" value="50"/> <param key="direct-deliver" value="false"/> </netty-acceptor> <in-vm-acceptor name="in-vm" server-id="0"/> </acceptors> <broadcast-groups> <broadcast-group name="bg-group1"> <socket-binding>messaging-group</socket-binding> <broadcast-period>5000</broadcast-period> <connector-ref> netty </connector-ref> </broadcast-group> </broadcast-groups> <discovery-groups> <discovery-group name="dg-group1"> <socket-binding>messaging-group</socket-binding> <refresh-timeout>10000</refresh-timeout> </discovery-group> </discovery-groups> <diverts> <divert name="CMPDatabase-changes-divert"> <address>jms.topic.clustered.CMPDatabaseChange</address> <forwarding-address>jms.topic.database-changes</forwarding-address> </divert> <divert name="CEMSDatabase-changes-divert"> <address>jms.topic.clustered.CEMSDatabaseChange</address> <forwarding-address>jms.topic.database-changes</forwarding-address> </divert> <divert name="ProvisioningDatabase-changes-divert"> <address>jms.topic.clustered.ProvisioningDatabaseChange</address> <forwarding-address>jms.topic.database-changes</forwarding-address> </divert> <divert name="ConnectionStatus-changes-divert"> <address>jms.topic.connectionStatusTopic</address> <forwarding-address>jms.topic.clustered.connectionStatusTopicCluster</forwarding-address> </divert> </diverts> <cluster-connections> <cluster-connection name="my-cluster-topics"> <address>jms.topic.clustered</address> <connector-ref>netty</connector-ref> <reconnect-attempts>5</reconnect-attempts> <discovery-group-ref discovery-group-name="dg-group1"/> </cluster-connection> <cluster-connection name="my-cluster-queues"> <address>jms.queue.clustered</address> <connector-ref>netty</connector-ref> <reconnect-attempts>5</reconnect-attempts> <discovery-group-ref discovery-group-name="dg-group1"/> </cluster-connection> <cluster-connection name="my-cluster-database-changes"> <address>jms.topic.database-changes</address> <connector-ref>netty</connector-ref> <reconnect-attempts>5</reconnect-attempts> <discovery-group-ref discovery-group-name="dg-group1"/> </cluster-connection> </cluster-connections> <security-settings> <security-setting match="#"> <permission type="send" roles="guest"/> <permission type="consume" roles="guest"/> <permission type="createNonDurableQueue" roles="guest"/> <permission type="deleteNonDurableQueue" roles="guest"/> </security-setting> </security-settings> <address-settings> <address-setting match="#"> <dead-letter-address>jms.queue.DLQ</dead-letter-address> <redelivery-delay>5000</redelivery-delay> <max-delivery-attempts>3</max-delivery-attempts> <max-size-bytes>104857600</max-size-bytes> <page-size-bytes>10485760</page-size-bytes> <address-full-policy>PAGE</address-full-policy> <message-counter-history-day-limit>10</message-counter-history-day-limit> <redistribution-delay>1000</redistribution-delay> </address-setting> </address-settings> <jms-connection-factories> <connection-factory name="InVmConnectionFactory"> <connectors> <connector-ref connector-name="in-vm"/> </connectors> <entries> <entry name="java:/ConnectionFactory"/> </entries> <connection-ttl>-1</connection-ttl> <reconnect-attempts>-1</reconnect-attempts> </connection-factory> <connection-factory name="RemoteConnectionFactory"> <connectors> <connector-ref connector-name="netty"/> </connectors> <entries> <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/> </entries> <ha>true</ha> <block-on-acknowledge>true</block-on-acknowledge> <retry-interval>1000</retry-interval> <retry-interval-multiplier>1.0</retry-interval-multiplier> <reconnect-attempts>-1</reconnect-attempts> </connection-factory> <pooled-connection-factory name="hornetq-ra"> <transaction mode="xa"/> <connectors> <connector-ref connector-name="in-vm"/> </connectors> </connectors> <entries> <entry name="java:/JmsXA"/> </entries> <connection-ttl>-1</connection-ttl> <reconnect-attempts>-1</reconnect-attempts> </pooled-connection-factory> </jms-connection-factories> <jms-destinations> <jms-queue name="DLQ"> <entry name="/queue/DLQ"/> </jms-queue> </jms-destinations> </hornetq-server>
从服务器收集了有问题的HornetQ主题状态，如下所示。 jms-topic = connectionStatusTopic的输出-JBOSS Node1
[domain @ jmp-Cluster：9999 /] / host = 005056a547be / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic：read-resource（include-runtime = true，include-defaults = true） { “结果” =>“成功”， “结果” => { “交货数量” => 289， “耐用消息计数” => 0， “ durable-subscription-count” => 0， “ entries” => [“ topic / connectionStatusTopic”]， “消息计数” => 289L， “添加邮件” => 184020L， “非持久消息计数” => 289， “ non-durable-subscription-count” => 6， “订阅数” => 6 “ temporary” =>否， “ topic-address” =>“ jms.topic.connectionStatusTopic” }
jms-topic = connectionStatusTopic-JBOSS Node2的输出
[domain @ jmp-Cluster：9999 /] / host = 005056a5078a / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic：read-resource（include-runtime = true，include-defaults = true） { “结果” =>“成功”， “结果” => { “交付数量” => 29， “耐用消息计数” => 0， “ durable-subscription-count” => 0， “ entries” => [“ topic / connectionStatusTopic”]， “消息计数” => 29L， “添加邮件” => 58548L， “非耐用消息数” => 29， “ non-durable-subscription-count” => 6， “订阅数” => 6 “ temporary” =>否， “ topic-address” =>“ jms.topic.connectionStatusTopic” }
jms-topic = connectionStatusTopic-JBOSS Node3的输出
[domain @ jmp-Cluster：9999 /] / host = 005056a56838 / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic：read-resource（include-runtime = true，include-defaults = true） { “结果” =>“成功”， “结果” => { “交货数量” => 3060， “耐用消息计数” => 0， “ durable-subscription-count” => 0， “ entries” => [“ topic / connectionStatusTopic”]， “消息计数” => 3060L， “添加邮件” => 285018L， “非持久消息计数” => 3060， “ non-durable-subscription-count” => 6， “订阅数” => 6 “ temporary” =>否， “ topic-address” =>“ jms.topic.connectionStatusTopic” }
jms-topic = connectionStatusTopic-JBOSS Node4的输出
[domain @ jmp-Cluster：9999 /] / host = 005056a5f871 / server = server1 / subsystem = messaging / hornetq-server = default / jms-topic = connectionStatusTopic：read-resource（include-runtime = true，include-defaults = true） { “结果” =>“成功”， “结果” => { “交付数量” => 144， “耐用消息计数” => 0， “ durable-subscription-count” => 0， “ entries” => [“ topic / connectionStatusTopic”]， “消息计数” => 144L， “添加邮件” => 69738L， “非持久消息计数” => 144， “ non-durable-subscription-count” => 6， “订阅数” => 6 “ temporary” =>否， “ topic-address” =>“ jms.topic.connectionStatusTopic” }
有一些反复印刷的警告，也附有。
[hornetq-core-client-2.3.21.2.Final-redhat-1.jar：2.3.21.2.Final-2019-02-27 08：43：34,387 WARN [org.hornetq.core.server]（线程9 （HornetQ-服务器-HornetQServerImpl :: serverUUID = e32b2ce0-4643-11e7-b8e5-43b6d7a70187-412588133）） HQ222192：重复缓存检测的大小（） 似乎太大了20,000。它不应该大于 可以压缩到配置缓冲区中的消息数 （）1,048,576。 2019-02-27 08：43：34,393警告 [org.hornetq.core.server]（线程21 （HornetQ-服务器-HornetQServerImpl :: serverUUID = e32b2ce0-4643-11e7-b8e5-43b6d7a70187-412588133）） HQ222192：重复缓存检测的大小（） 似乎太大了20,000。它不应该大于 可以压缩到配置缓冲区中的消息数 （）1,048,576。