当前位置: 首页 > 知识库问答 >
问题:

集群模式下的JBoss EAP7.1集成ActiveMQ Artemis消息重新分发不起作用

吕昀
2023-03-14

在https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/clusters_overview中的第29项之后,重新分发测试不起作用。

测试用例:1个jboss主程序和2个jboss从程序。我在artemis中创建了“Respostacsu”队列,并在上面发布了一条消息。消息到达奴隶一号。这没有关联的监听器用于它们的correlationId,因此不会从队列中移除消息。应该根据RedHat(redistribution-delay=0和message-load-balancing-type=ON_DEMAND)文档将消息转发到下一个集群机器(slave-2)。然而,该消息没有被重定向,并保留在slave-1中。

有什么建议吗?

JBoss EAP 7.1 master domain.xml文件:

...
<socket-binding-group name="full-ha-sockets" default-interface="public">
    <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
    <socket-binding name="http" port="${jboss.http.port:8080}"/>
    <socket-binding name="https" port="${jboss.https.port:8443}"/>
    <socket-binding name="iiop" interface="unsecure" port="3528"/>
    <socket-binding name="iiop-ssl" interface="unsecure" port="3529"/>
    <socket-binding name="jgroups-mping" interface="private" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
    <socket-binding name="jgroups-tcp" interface="private" port="7600"/>
    <socket-binding name="jgroups-udp" interface="private" port="55200" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45688"/>
    <socket-binding name="modcluster" port="0" multicast-address="${jboss.modcluster.multicast.address:224.0.1.105}" multicast-port="23364"/>
    <socket-binding name="txn-recovery-environment" port="4712"/>
    <socket-binding name="txn-status-manager" port="4713"/>
    <socket-binding name="messaging-group" interface="private" port="5432" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="9876"/>
    <outbound-socket-binding name="mail-smtp">
        <remote-destination host="localhost" port="25"/>
    </outbound-socket-binding>
</socket-binding-group>

...
<subsystem xmlns="urn:jboss:domain:messaging-activemq:2.0">
    <server name="default">
        <security enabled="false"/>
        <cluster user="mbuser" password="mbsenha"/>
        <security-setting name="#">
            <role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
        </security-setting>
        <address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10" redistribution-delay="0"/>
        <address-setting name="jms.#" redistribution-delay="0"/>
        <http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
        <http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
            <param name="batch-delay" value="50"/>
        </http-connector>
        <in-vm-connector name="in-vm" server-id="0">
            <param name="buffer-pooling" value="false"/>
        </in-vm-connector>
        <http-acceptor name="http-acceptor" http-listener="default"/>
        <http-acceptor name="http-acceptor-throughput" http-listener="default">
            <param name="batch-delay" value="50"/>
            <param name="direct-deliver" value="false"/>
        </http-acceptor>
        <in-vm-acceptor name="in-vm" server-id="0">
            <param name="buffer-pooling" value="false"/>
        </in-vm-acceptor>
        <broadcast-group name="mb-broadcast-group" socket-binding="messaging-group" broadcast-period="2000" connectors="http-connector"/>
        <discovery-group name="mb-discovery-group" socket-binding="messaging-group" refresh-timeout="10000"/>
        <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" use-duplicate-detection="false" message-load-balancing-type="ON_DEMAND" discovery-group="mb-discovery-group"/>
        <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
        <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
        <jms-queue name="solicitacaoCsu" entries="java:/jms/queue/QL.REQ.BKLQ001Z" durable="false"/>
        <jms-queue name="respostaCsu" entries="java:/jms/queue/QL.RSP.BKLQ001Z" durable="false"/>
        <connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
        <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1"/>
        <pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
    </server>
</subsystem>

共有1个答案

柯易安
2023-03-14

重新分发不支持选择器。但是,初始分配有。因此,您应该在发送请求之前创建使用者,以便在发送答复时使用者在队列中。

 类似资料:
  • 我使用Artemis 2.6.3。我在对称拓扑中创建了2个节点。 生产者和消费者由这里描述的Spring Broker Relay处理。它写入地址(多播),生成的队列是不持久的。 消费者仅在连接到节点1(产生消息的位置)时接收消息。我可以让一个连接到节点1接收消息,另一个连接到节点2不接收消息。如果两个节点都在节点2上,则无人接收消息。 我认为信息再分配不起作用,但无法找出原因。我遵循了示例和可用

  • 我在Kubernetes有一个Artemis集群,有3组主/从: 我使用Spring boot JmsListener来使用发送到通配符队列的消息,如下所示。 master-0上通配符队列的属性如下所示: 目前使用的Artemis版本是2.17.0。下面是我在master-0中的集群配置。除了被更改以匹配代理之外,其他代理的配置是相同的: 从堆栈溢出的另一个答案中,我了解到我的高可用性拓扑是冗余的

  • DemohornetQServerReceiveApplication: Application.Properties(ServerReceive) 启动这两个应用程序后,日志输出显示如下: 消息似乎没有从ServerEnd转发到ServerReceive。 我做了更多的测试,创建了另外两个Spring Boot应用程序(ClientSend和ClientReceive),它们没有嵌入Hornet

  • Redis streams是否受益于群集模式?假设您有10个流,它们是分布在集群中还是全部分布在同一个节点上?我计划使用Redis streams实现真正的高吞吐量(每秒200万条消息),因此我担心Redis streams在这种规模下的性能。 如果Redis streams不能在集群模式下进行开箱即用的扩展,那么任何关于水平扩展Redis streams的指导都会非常棒。

  • /usr/local/spark-1.2.1-bin-hadoop2.4/bin/--类com.fst.firststep.aggregator.firststepmessageProcessor--主spark://ec2-xx-xx-xx-xx.compute-1.amazonaws.com:7077--部署模式集群--监督文件:///home/xyz/sparkstreaming-0.0.1

  • 最近,我在使用logback.xml作为日志记录时,在独立集群模式下的Flink日志记录中遇到了一个问题。我的要求是,我的所有作业都应该登录到特定的文件夹中,我的flink框架日志应该放在单独的文件夹中,而且对于在我的flink集群中运行的每个作业,应该有单独的文件夹用于不同的作业。我在我的本地集群中测试了它,它运行良好,我得到了所有的日志,与我提交的Flink作业相关的单独文件夹,但一旦我在独立