消息传递系统允许您松散耦合异构系统，同时提高可靠性。与基于远程过程调用(RPC)模式的系统不同，消息传递系统主要使用异步消息传递模式，请求和响应之间没有紧密关系。大多数消息传递系统足够灵活，足以在需要时支持请求响应模式，但这不是消息传递系统的主要功能。

消息传递系统将消息的发件人与其消费者分离。事实上，消息的发送者和使用者完全独立，彼此不了解，这使得您可以创建灵活、松散耦合的系统。大型企业通常使用消息传递系统来实施松散耦合异构系统的消息总线。消息总线可形成企业服务总线(ESB)的核心。利用消息总线分离分散分散的系统，让系统能够更加轻松地发展并适应。它还能够更加灵活地添加新系统或停用旧系统，因为它们之间没有相互依赖的混乱。

消息传递系统还可以纳入诸如以下概念：确保可靠消息传递、将发送或消费多条消息聚合为一个工作单元，以及允许消息避免服务器故障或重新启动的持久性。

大多数消息传递系统支持两种消息传递样式：点对点模式和 发布订阅模式。

Java 消息传递服务(JMS)2.0 在 JSR 343 中定义。Jakarta EE 同等规范是 Jakarta Messaging。JMS 是一种 Java API，提供点对点和发布订阅者消息传递样式。JMS 还包含了事务的使用。JMS 不定义标准线路格式，因此 JMS 提供商可能全部使用标准 API，但可能会使用不同的内部线协议在客户端和服务器之间进行通信。

JMS 目的地以及 JMS 连接工厂是 JMS 管理对象。目的地供 JMS 客户端用于生成和使用消息。该目的地允许 JMS 客户端在生成消息时使用消息时指定目标以及消息来源。使用发布订阅模式时，目的地称为主题。使用点对点模式时，目的地称为队列。

应用可能会使用在服务器端配置并且通常通过 JNDI 访问的不同 JMS 目的地。

Apache ActiveMQ Artemis 是一个用于异步消息传递系统的开源项目。它是高性能、嵌入式、集群化并支持多种协议。JBoss EAP 7 将 Apache ActiveMQ Artemis 用作其 JMS 代理，并使用 messaging-activemq 子系统进行配置。这完全取代了 HornetQ 代理，但仍保持了与 JBoss EAP 6 的协议兼容性。

核心 ActiveMQ Artemis 是 JMS-agnostic，提供非 JMS API，称为核心 API。ActiveMQ Artemis 还提供 JMS 客户端 API，它使用学术层在核心 API 基础上实施 JMS 语义。本质上，JMS 交互通过 JMS 客户端 API 在客户端上转换为核心 API 操作。从那里，所有操作都使用核心客户端 API 和 Apache ActiveMQ Artemis wire 格式发送。服务器本身仅使用 core API。如需有关核心 API 及其概念的更多详细信息，请参阅 ActiveMQ Artemis 文档。

让我们快速讨论 JMS 目的地如何映射到 Apache ActiveMQ Artemis 地址。

Apache ActiveMQ Artemis 核心是 JMS-agnostic.它没有任何 JMS 主题的概念。JMS 主题在 core 中作为绑定有零个或多个队列的地址（主题名称）实施。绑定到该地址的每个队列都代表一个主题订阅。类似地，JMS 队列作为地址（JMS 队列名称）实施，其绑定了一个队列，它代表 JMS 队列。

按照惯例，所有 JMS 队列映射到核心队列，其中核心队列名称具有 string jms.queue. 前缀为它。例如，名称为 Order .europe 的 JMS 队列将使用 name jms.queue.orders.europe 映射到核心队列。绑定核心队列的地址也由核心队列名称提供。

对于 JMS 主题，通过将 string jms.topic. 添加到 JMS 主题的名称来为代表订阅的队列绑定的地址。例如，名称为 news.europe 的 JMS 主题将映射到核心 address jms.topic.news.europe。

换句话说，如果您发送 JMS 消息到带有名称 Order .europe 的 JMS 队列，它会在服务器上路由到绑定到 address jms.queue.orders.europe 的任何核心队列。如果您发送 JMS 消息到名称为 news.europe 的 JMS 主题，它会在服务器上路由到绑定到 address jms.topic.news.europe 的任何核心队列。

如果要使用名称 Order .europe 配置 JMS 队列的设置，您需要配置对应的内核 queue jms.queue.orders.europe ：

<!-- expired messages in JMS Queue "orders.europe" will be sent to the JMS Queue "expiry.europe" -->
<address-setting match="jms.queue.orders.europe">
   <expiry-address>jms.queue.expiry.europe</expiry-address>
   ...
</address-setting>

helloworld-mdb quickstart 使用一个简单的消息驱动 Bean 来演示基本的 Jakarta EE 消息传递功能。在回顾基本配置时，快速入门和运行是向自己介绍 JBoss EAP 消息传递服务器所含功能的一种好方法。

构建和部署 helloworld-mdb Quickstart

有关构建和部署 helloworld-mdb 快速启动的说明，请参阅由快速入门提供的 README.md 文件中的说明。您将需要启动 JBoss EAP 服务器，指定包含 messaging-activemq 子系统 的完整 配置。有关使用不同配置文件启动 JBoss EAP 的详细信息，请参阅 README.md 文件或 JBoss EAP 配置指南。

在使用 full 或 full - ha 配置启动 JBoss EAP 服务器时，包含 messaging- activemq 子系统的默认配置。full-ha 选项包括 集群和 高可用性 等功能的高级配置。

虽然不需要，但 建议您使用 helloworld-mdb 快速入门 作为有效的示例，以便与配置概述一起运行。

如需有关 messaging-activemq 子系统中所有可用设置的信息，请参见 EAP_HOME/docs/schema/ 目录中的架构定义，或者从管理 CLI 对子系统运行 read-resource-description 操作，如下所示：

/subsystem=messaging-activemq:read-resource-description(recursive=true)

服务器配置文件中的以下扩展名指示 JBoss EAP 将 messaging-activemq 子系统作为其运行时的一部分：

<extensions>
  ...
  <extension module="org.wildfly.extension.messaging-activemq"/>
  ...
</extensions>

messaging-activemq 子系统的配置包含在 <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> 元素中。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
    <server name="default">
        <cluster password="${jboss.messaging.cluster.password:CHANGE ME!!}"/>
        <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="1000"/>
        <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"/>
        <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"/>
        <broadcast-group name="bg-group1" connectors="http-connector" jgroups-cluster="activemq-cluster"/>
        <discovery-group name="dg-group1" jgroups-cluster="activemq-cluster"/>
        <cluster-connection name="my-cluster" address="jms" connector-name="http-connector" discovery-group="dg-group1"/>
        <jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
        <jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
        <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
        <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
        <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
    </server>
</subsystem>

连接事实

消息传递客户端使用 JMS ConnectionFactory 对象来连接服务器。默认 JBoss EAP 配置定义多种连接工厂：请注意，有 <connection-factory> 用于 in-vm、http 和池化连接。

  <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory"/>
  <connection-factory name="RemoteConnectionFactory" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
  <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>

如需了解更多详细信息，请参阅 配置连接事实部分。

连接器和 Acceptors

每一 JMS 连接工厂使用连接器启用从客户端或消费者到消息传递服务器的 JMS 通信。连接器对象定义用于连接消息传递服务器的传输和参数。其对应对象是接收器对象，用于标识消息传递服务器接受的连接类型。

默认的 JBoss EAP 配置定义了多个连接器和接收器。

<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"/>

<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>

详情请查看 Acceptors 和 Connectors 部分。

套接字绑定组

默认连接器 的 socket-binding 属性引用名为 http 的套接字绑定。使用 http 连接器，因为 JBoss EAP 可以在标准 Web 端口上多路复用请求。

您可以在配置文件的其他位置找到此 socket-binding 作为 <socket-binding-group> 部分的一部分。请注意 http 和 https 套接字绑定的配置如何出现在 <socket-binding-groups> 元素中：

<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
   ...
  <socket-binding name="http" port="${jboss.http.port:8080}"/>
  <socket-binding name="https" port="${jboss.https.port:8443}"/>
   ...
</socket-binding-group>

如需有关套接字绑定的信息，请参阅 JBoss EAP 配置指南中的配置套接字绑定 。

消息传递安全性

在首次安装 JBoss EAP 时，messaging -activemq 子系统包含一个 security-setting 元素：

<security-setting name="#">
  <role name="guest" delete-non-durable-queue="true" create-non-durable-queue="true" consume="true" send="true"/>
</security-setting>

这声明，任何具有 guest 角色的用户都可以访问服务器上的任何地址，如通配符 # 所述。有关通配符语法的更多信息，请参阅配置地址设置。

有关保护目的地和远程连接的更多信息，请参阅配置消息传递安全性。

消息传递目标

完整和全 ha 配置包括两个有帮助的队列，JBoss EAP 可以使用这些队列存放已过期或无法路由到正确目的地的消息。

<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>

您可以使用以下方法之一在 JBoss EAP 中添加自己的消息传递目的地：

如需了解更多详细信息，请参阅配置消息传递目标。

要添加 JMS 队列，请在管理 CLI 中使用 jms-queue 命令：

jms-queue add --queue-address=myQueue --entries=[queue/myQueue jms/queue/myQueue java:jboss/exported/jms/queue/myQueue]

注意 entries 属性如何是一个包含由单个空格分隔的多个 JNDI 名称的列表。另请注意，使用方括号 [] 来括起 JNDI 名称列表。queue-address 提供路由配置，条目 提供 JNDI 名称列表，客户端可用于查找队列。

读取队列的属性

您可以在管理 CLI 中使用 jms-queue 命令读取队列的配置。

jms-queue read-resource --queue-address=myQueue

或者，您可以使用管理 CLI 访问 messaging-activemq 子系统来读取队列配置：

/subsystem=messaging-activemq/server=default/jms-queue=myQueue:read-resource()
{
    "outcome" => "success",
    "result" => {
        "durable" => true,
        "entries" => ["queue/myQueue jms/queue/myQueue java:jboss/exported/jms/queue/myQueue"],
        "legacy-entries" => undefined,
        "selector" => undefined
    }
}

a jms-queue的属性

输入以下命令时，管理 CLI 显示 jms-queue 配置元素的所有属性：

/subsystem=messaging-activemq/server=default/jms-queue=*:read-resource-description()

下表提供了 a jms-queue 的所有属性：

添加或读取主题与添加队列非常类似：

jms-topic add --topic-address=myTopic --entries=[topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic]

阅读主题的属性

读取主题属性的语法也类似于用于队列的语法：

jms-topic read-resource --topic-address=myTopic

entries
  topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic
legacy-entries=n/a

/subsystem=messaging-activemq/server=default/jms-topic=myTopic:read-resource
{
    "outcome" => "success",
    "result" => {
        "entries" => ["topic/myTopic jms/topic/myTopic java:jboss/exported/jms/topic/myTopic"],
        "legacy-entries" => undefined
    }
}

a jms-topic的属性

输入以下命令时，管理 CLI 显示 jms-topic 配置元素的所有属性：

/subsystem=messaging-activemq/server=default/jms-topic=*:read-resource-description()

下表列出了 a jms-topic 的属性：

队列或主题必须绑定到 java:jboss/exported 命名空间，以便远程客户端能够进行查找。在进行查找时，客户端必须使用 java:jboss/exported/ 后的文本。例如，名为 testQueue 的队列为其 条目 的 list jms/queue/test java:jboss/exported/jms/queue/test.希望将消息发送到 testQueue 的远程客户端将使用 string jms/queue/test 查找队列。另一方面，本地客户端可以通过 java:jboss/exported/jms/queue/test、java:jms/queue/test 或更多 simple jms/queue/test 进行 查找。

管理 CLI 帮助

您可以使用 --help --command s 标志找到有关 jms-queue 和jms -topic 命令的更多信息：

jms-queue --help --commands

jms-topic --help --commands

通配符可用于将相似的地址与单个语句匹配，很像有多少系统使用星号字符 * 将多个文件或字符串与单个查询匹配。下表列出了可用于定义 <address-setting> 的特殊字符。

下表中的示例说明了如何使用通配符匹配一组地址。

开箱即用，JBoss EAP 包含了单一 address-setting 元素，作为 messaging-activemq 子系统配置的一部分：

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
      ...
      <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" />
      ...
  </server>
</subsystem>

使用管理 CLI 配置地址设置

配置地址设置可使用管理 CLI 或管理控制台进行，但管理 CLI 会公开更多用于编辑的配置属性。 有关属性的完整列表，请参阅本指南附录中的地址设置属性。

添加新 address-setting

如果需要，使用 add 操作创建新的地址设置。您可以从管理 CLI 会话的根目录运行此命令，以下示例中创建名为 的新模式。您可以包含 address-setting 的配置属性。下面是创建一个新的 address-setting 匹配 news.europe.#，其 dead-letter-address 属性设置为队列 DLQ.news，该属性是提前创建的。单机服务器和受管域都使用 full 配置文件的示例分别显示。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:add(dead-letter-address=DLQ.news)

编辑 address-setting 属性

使用 write-attribute 操作，将新值写入到属性。您可以使用 Tab 补全来帮助完成键入的命令字符串，以及公开可用的属性。以下示例将 max-delivery-attempts 值更新为 10。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:write-attribute(name=max-delivery-attempts,value=10)

读取 address-setting 属性

使用 include- runtime=true 参数运行 read-resource 操作来公开服务器模式中的所有当前值，以确认值已更改。

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:read-resource(include-runtime=true)

/profile=full/subsystem=messaging-activemq/server=default/address-setting=news.europe.#/:read-resource(include-runtime=true)

使用管理控制台配置地址设置

您可以按照以下步骤使用管理控制台创建和查看地址设置：

请记住，添加新模式时，如 news.europe.#，Pattern 字段引用 address-setting 元素的 name 属性。在使用管理 CLI 读取或写入属性时，您可以输入这个值。

在使用管理控制台时，您只能编辑 dead-letter- address、redelivery -delay 和 max-delivery-attempts 属性。其他属性必须通过管理 CLI 进行配置。

为消息传递服务器配置全局资源使用量

address-setting 元素中的三个 属性可帮助您控制消息传递服务器的全局资源使用情况：

最后值队列是特殊队列，当将值相同的新消息放入队列中时，丢弃任何消息。换句话说，最后一个值队列仅保留最后一个值。最后值队列的典型应用可能涉及股票价格，您仅对特定股票的最新价格感兴趣。

配置 Last-value Queues

last-value 队列在 address-setting 配置元素中定义：

<address-setting name="jms.queue.lastValueQueue" last-value-queue="true" />

使用管理 CLI 为给定 address -setting 读取 last-value- queue 的值：

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#:read-attribute(name=last-value-queue)
{
    "outcome" => "success",
    "result" => false
}

last-value-queue 的可接受的值为 true 或 false。使用管理 CLI 设置任一值，如下所示：

/subsystem=messaging-activemq/server=default/address-setting=news.europe.#:write-attribute(name=last-value-queue,value=true)

/subsystem=messaging-activemq/server=default/address-setting=news.asia.#:write-attribute(name=last-value-queue,value=false)

使用 Last-value 属性

用于标识最后一个值的属性名称为 _AMQ_LVQ_NAME （或核心 API 中的恒定 Message.HDR_LAST_VALUE_NAME ）。让以下 Java 代码演示了如何使用 last-value 属性。

TextMessage message = session.createTextMessage("My 1st message with the last-value property set");
message.setStringProperty("_AMQ_LVQ_NAME", "MY_MESSAGE");
producer.send(message);

message = session.createTextMessage("My 2nd message with the last-value property set");
message.setStringProperty("_AMQ_LVQ_NAME", "MY_MESSAGE");
producer.send(message);

TextMessage messageReceived = (TextMessage)messageConsumer.receive(5000);
System.out.format("Received message: %s\n", messageReceived.getText());

在上例中，客户端的输出将是 "My 2nd 消息，并设置了 last-value 属性"，因为两条消息都 设置为 "MY_MESSAGE"，在队列中在第一个消息后收到第二条消息。

除了保护远程连接到消息传递服务器外，您还可以配置特定目的地的安全性。这可以通过使用 security-setting 配置元素添加安全约束来实现。JBoss EAP 消息传递默认配置有 security-setting，如以下管理 CLI 命令的输出所示：

/subsystem=messaging-activemq/server=default:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        ....
        "security-setting" => {"#" => {"role" => {"guest" => {
            "consume" => true,
            "create-durable-queue" => false,
            "create-non-durable-queue" => true,
            "delete-durable-queue" => false,
            "delete-non-durable-queue" => true,
            "manage" => false,
            "send" => true
        }}}}
    }
}

security-setting 选项在 name 字段中使用通配符来处理要应用安全性约束的目的地。单个 # 的值将匹配任何地址。有关在安全约束中使用通配符的更多信息，请参阅基于角色的安全性。

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#:add()
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=dev:add(consume=true,delete-non-durable-queue=true,create-non-durable-queue=true,send=true)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/security-setting=news.europe.#/role=admin:add(manage=true,create-durable-queue=true,delete-durable-queue=true)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=security-setting,recursive=true)
{
    "outcome" => "success",
    "result" => {
        "#" => {"role" => {"guest" => {
            "consume" => true,
            "create-durable-queue" => false,
            "create-non-durable-queue" => true,
            "delete-durable-queue" => false,
            "delete-non-durable-queue" => true,
            "manage" => false,
            "send" => true
        }}},
        "news.europe.#" => {"role" => {
            "dev" => {
                "consume" => true,
                "create-durable-queue" => false,
                "create-non-durable-queue" => true,
                "delete-durable-queue" => false,
                "delete-non-durable-queue" => true,
                "manage" => false,
                "send" => true
            },
            "admin" => {
                "consume" => false,
                "create-durable-queue" => true,
                "create-non-durable-queue" => false,
                "delete-durable-queue" => true,
                "delete-non-durable-queue" => false,
                "manage" => true,
                "send" => false
            }
        }}
    }

由于 ObjectMessage 可以包含潜在的危险对象，ActiveMQ Artemis 提供了一个简单的类过滤机制，以控制哪些软件包和类值得信任且不被信任。您可以将其类从可信软件包中的对象添加到白名单，以指明它们可以无问题地进行非序列化。您可以将其类从不受信任的软件包添加到黑列表中的对象，以防止它们被反序列化。

ActiveMQ Artemis 过滤对象以进行反序列化，如下所示：

如果对象全名与列表中的某一条目完全匹配，或者其软件包与列表中某一条目匹配，或者是列表中某一条目的子软件包，则对象被视为匹配项。

您可以使用 deserialization- white-list 和 deserialization- black-list 属性 ，在 connection-factory 和 pooled-connection - factory 中指定哪些对象可以被反序列化。deserialization-white-list 属性用于定义允许进行反序列化的类或软件包的列表。deserialization-black-list 属性用于定义不允许进行反序列化的类或软件包的列表。

以下命令为 RemoteConnectionFactory 连接工厂创建一个黑名单，并为默认服务器创建 activemq-ra 池连接工厂的白名单。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=deserialization-black-list,value=[my.untrusted.package,another.untrusted.package])
/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=deserialization-white-list,value=[my.trusted.package])

这些命令在 messaging-activemq 子系统中生成以下配置：

<connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector" ha="true" block-on-acknowledge="true" reconnect-attempts="-1" deserialization-black-list="my.untrusted.package another.untrusted.package"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" deserialization-white-list="my.trusted.package" transaction="xa"/>

有关连接工厂和池连接工厂的详情，请参考本指南中的配置连接工厂。

您还可以通过配置激活属性在 MDB 中指定哪些对象可以被反序列化。deserializationWhiteList 属性用于定义允许进行反序列化的类或软件包的列表。deserializationBlackList 属性用于定义不允许进行反序列化的类或软件包列表。有关激活属性的更多信息，请参阅为 JBoss EAP 开发 EJB 应用时使用 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html-single/developing_ejb_applications/#configuring_mdbs_using_deployment_descriptor 部署描述符配置 MDB。

messaging - activemq 子系统中服务器上的 security- invalidation-interval 属性决定了在必须重新授权前缓存授权的时长。

系统授权用户在地址上执行操作时，将缓存授权。下次同一用户在同一地址上执行相同的操作时，系统会将缓存的授权用于操作。

例如，用户 admin 尝试向地址 新闻 发送消息。系统授权操作，并缓存授权。下一次 管理员 尝试向 news 发送消息时 ， 系统会使用缓存的授权。

如果缓存的授权没有在无效间隔指定的时间内再次使用，则会从缓存中清除授权。系统必须重新授权用户，以便在请求的地址执行请求的操作。

安装后，JBoss EAP 假定默认值为 10000 毫秒（10 秒）。

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 10000L
}

security-invalidation-interval 属性可以配置。例如，以下命令将间隔更新为 60000 毫秒（60 秒或一分钟）。

/subsystem=messaging-activemq/server=default:write-attribute(name=security-invalidation-interval,value=60000)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}

您必须重新加载服务器才能使配置修改生效。

读取 属性会显示新结果。

/subsystem=messaging-activemq/server=default:read-attribute(name=security-invalidation-interval)
{
    "outcome" => "success",
    "result" => 60000L
}

JBoss EAP 配置中定义了三种主要类型的接收器和连接器：

in-vm ：In-vm 是 Intra 虚拟机的缩写。如果客户端和服务器都在同一个 JVM 中运行，例如在同一 JBoss EAP 实例中运行的 Message Driven Beans(MDB)，可使用这种连接器类型。

HTTP ：在不同 JVM 中运行客户端和服务器时使用。使用 undertow 子系统的默认端口 8080，因此能够通过 HTTP 进行多路消息传递通信。由于端口管理等注意事项，红帽建议在客户端和服务器在不同 JVM 中运行 http 连接器，特别是在云环境中。

远程： 远程 传输是基于 Netty 的组件，当客户端和服务器在不同 JVM 中运行时，用于原生 TCP 通信。在无法使用 http 时替代 http。

客户端必须使用与服务器接收器之一兼容的连接器。例如，只有 in-vm-connector 可以连接到 in-vm-acceptor，并且只有 http-connector 可以连接到 http-acceptor 等。

您可以使用 read-children-attributes 操作，显示管理 CLI 列表给定接收器或连接器类型的属性。例如，要查看您将输入的默认消息传递服务器的所有 http-connectors 属性：

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-connector,include-runtime=true)

所有 http-acceptors 的属性都使用类似的命令读取：

/subsystem=messaging-activemq/server=default:read-children-resources(child-type=http-acceptor,include-runtime=true)

其他接收器和连接器类型遵循相同的语法。仅向 子类型 提供接收器或连接器类型，如 remote-connector 或 in -vm-acceptor。

接收器定义 JBoss EAP 集成消息传递服务器接受哪些类型的连接。您可以定义每台服务器任意数量的接收器。以下示例配置是从默认的 full-ha 配置文件修改的，并提供了每个接收器类型的示例。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <http-acceptor name="http-acceptor" http-listener="default"/>
    <remote-acceptor name="legacy-messaging-acceptor" socket-binding="legacy-messaging"/>
    <in-vm-acceptor name="in-vm" server-id="0"/>
    ...
  </server>
</subsystem>

在上述配置中，http -acceptor 使用 Undertow 的默认 http-listener，它侦听 JBoss EAP 的默认 http 端口 8080。http-listener 在 undertow 子系统中定义：

<subsystem xmlns="urn:jboss:domain:undertow:10.0">
  ...
  <server name="default-server">
    <http-listener name="default" redirect-socket="https" socket-binding="http"/>
    ...
  </server>
  ...
</subsystem>

另请注意，上面的 remote-acceptor 如何使用名为 legacy -messaging 的 socket-binding，这会在稍后配置中作为服务器的默认 socket-binding-group 的一部分进行定义。

<server xmlns="urn:jboss:domain:8.0">
  ...
  <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
      ...
      <socket-binding name="legacy-messaging" port="5445"/>
      ...
  </socket-binding-group>
</server>

在本例中，传统-messaging socket-binding 将 JBoss EAP 绑定到端口 5445，上面的远程 接收器则声明代表 messaging-activemq 子系统供传统客户端使用的端口。

最后，in-vm-acceptor 对 server-id 属性使用唯一值，以便此服务器实例可以和可能在同一 JVM 中运行的其他服务器区分开来。

连接器定义如何连接集成 JBoss EAP 消息传递服务器，供客户端用于连接。

您可能会知道为什么服务器上定义了连接器（当客户端实际使用时）。原因包括：

您可以定义每台服务器任意数量的连接器。以下示例配置基于 full-ha 配置配置文件，并包含每种类型的连接器。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <http-connector name="http-connector" endpoint="http-acceptor" socket-binding="http" server-name="messaging-server-1"/>
    <remote-connector name="legacy-remoting-connector" socket-binding="legacy-remoting"/>
    <in-vm-connector name="in-vm" server-id="0"/>
    ...
  </server>
</subsystem>

与 full -ha 配置文件中的 http- acceptor 一样，http-connector 使用 undertow 子系统定义的默认 http-listener。endpoint 属性声明要连接的 http-acceptor。在这种情况下，连接器将连接到默认的 http-acceptor。

JBoss EAP 7.1 为 http -connector 引入了一个新的 server- name 属性。此新属性为可选，但需要能够在运行多个 ActiveMQ Artemis 实例的远程服务器上连接正确的 http-acceptor。如果未定义此属性，则该值在运行时解析为定义了连接器的父 ActiveMQ Artemis 服务器的名称。

另外，请注意 remote-connector 引用的 socket-binding 与其远程接收器相同。最后，in-vm-connector 对 server-id 使用与 in-vm-acceptor 相同的值，因为它们在同一服务器实例中运行。

AMQ121005: Invalid "host" value "0.0.0.0" detected for "connector" connector. Switching to <HOST_NAME>. If this new address is incorrect please manually configure the connector to use the proper one.

连接器和接收器有许多配置选项。它们在配置中显示为子 <param> 元素。每个 <param> 元素包含一个 名称和 值 属性对，由默认的基于 Netty 的工厂类理解和使用，该类负责实例化连接器或接收器。

在管理 CLI 中，每个远程连接器或接收器元素都包含参数名称和值对的内部映射。例如，要将新的 param 添加到 名为 myRemote 的远程 连接器中，请使用以下命令：

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:map-put(name=params,key=foo,value=bar)

使用类似语法检索参数值。

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:map-get(name=params,key=foo)
{
    "outcome" => "success",
    "result" => "bar"
}

您还可以在创建接收器或连接器时包含参数，如下例所示。

/subsystem=messaging-activemq/server=default/remote-connector=myRemote:add(socket-binding=mysocket,params={foo=bar,foo2=bar2})

如果要将客户端连接到服务器，您必须有一个正确的连接器。有两种方法可以做到这一点。您可以使用服务器上配置的 ConnectionFactory，可通过 JNDI 查找获取。或者，也可以使用 ActiveMQ Artemis 核心 API，并在客户端上配置整个 ConnectionFactory。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    [...]
    <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"/>
    [...]
    <connection-factory name="InVmConnectionFactory" connectors="in-vm" entries="java:/ConnectionFactory" />
    <pooled-connection-factory name="activemq-ra" transaction="xa" connectors="in-vm" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory"/>
    [...]
    </server>
</subsystem>

<connection-factory
  name="InVmConnectionFactory"
  entries="java:/ConnectionFactory"
  connectors="in-vm" />

InitialContext ctx = new InitialContext();
ConnectionFactory cf = (ConnectionFactory)ctx.lookup("ConnectionFactory");
Connection connection = cf.createConnection();

<connection-factory
  name="RemoteConnectionFactory"
  scheduled-thread-pool-max-size="10"
  entries="java:jboss/exported/jms/RemoteConnectionFactory"
  connectors="http-connector"/>

final Properties env = new Properties();
env.put(Context.INITIAL_CONTEXT_FACTORY, "org.wildfly.naming.client.WildFlyInitialContextFactory");
env.put(Context.PROVIDER_URL, "http-remoting://remotehost:8080");
InitialContext remotingCtx = new InitialContext(env);
ConnectionFactory cf = (ConnectionFactory) remotingCtx.lookup("jms/RemoteConnectionFactory");

<dependencies>
  <dependency>
    <groupId>org.wildfly</groupId>
    <artifactId>wildfly-jms-client-bom</artifactId>
    <type>pom</type>
  </dependency>
</dependencies>

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(new TransportConfiguration(InVMConnectorFactory.class.getName()));

ClientSessionFactory factory =  locator.createClientSessionFactory();

ClientSession session = factory.createSession();

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(
  new TransportConfiguration( InVMConnectorFactory.class.getName()));

// In this simple example, we just use one session for both
// producing and consuming
ClientSessionFactory factory =  locator.createClientSessionFactory();
ClientSession session = factory.createSession();

// A producer is associated with an address ...
ClientProducer producer = session.createProducer("example");
ClientMessage message = session.createMessage(true);
message.getBodyBuffer().writeString("Hello");

// We need a queue attached to the address ...
session.createQueue("example", "example", true);

// And a consumer attached to the queue ...
ClientConsumer consumer = session.createConsumer("example");

// Once we have a queue, we can send the message ...
producer.send(message);

// We need to start the session before we can -receive- messages ...
session.start();
ClientMessage msgReceived = consumer.receive();

System.out.println("message = " + msgReceived.getBodyBuffer().readString());

session.close();

将 JBoss EAP 用作负载平衡器时，客户端可以调用静态 Undertow HTTP 负载平衡器后或 mod_cluster 负载平衡器后面的消息传递服务器。

要支持通过静态负载均衡器调用消息传递服务器的消息传递客户端的配置必须满足以下要求：

有关使用 mod_cluster 将 Undertow 配置为负载平衡器的详细信息，请将 Undertow 配置为使用 mod_cluster 的负载平衡器 。

配置消息客户端以通过负载均衡器进行通信

连接到负载均衡器的客户端必须配置为重复使用初始连接，而不是使用集群拓扑连接到负载均衡器。

重新使用初始连接可确保客户端连接到同一服务器。使用集群拓扑可能会导致消息定向到不同的服务器，这可能会导致事务处理中断。

用于连接负载平衡器的连接工厂或池式连接工厂必须通过属性 use-topology-for-load-balancing 设置为 false 来配置。以下示例演示了如何在 CLI 中定义此配置：

/subsystem=messaging-activemq/pooled-connection-factory=remote-artemis:write-attribute(name=use-topology-for-load-balancing, value=false)

配置后端 worker

只有在负载均衡器后计划进行 JNDI 查找时，您必须配置后端消息传递工作程序。

JBoss EAP 随附两个持久化选项，用于存储绑定数据和消息：

JBoss EAP 消息传递附带了高性能、基于文件的日志，针对消息传递进行了优化。

JBoss EAP 消息传递日志具有可配置的文件大小且仅附加，这可通过启用单写操作来提高性能。它由磁盘上的一组文件组成，这些文件最初会预先创建成固定大小并填写 padding。在执行添加消息、删除消息和更新消息等服务器操作时，操作的记录将附加到日志中，直到日志文件已满，此时使用下一个日志文件。

复杂的垃圾收集算法决定了在所有数据都被删除后是否可以回收和重新使用日志文件。紧凑算法从日志文件中删除死空间并压缩数据。

日志还完全支持本地和 XA 事务。

/subsystem=messaging-activemq/server=default/path=bindings-directory:read-resource

{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/bindings",
        "relative-to" => "jboss.server.data.dir"
    }
}

/subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=path,value=PATH_LOCATION)

/subsystem=messaging-activemq/server=default/path=bindings-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

/subsystem=messaging-activemq/server=default:write-attribute(name=create-bindings-dir,value=TRUE/FALSE)

/subsystem=messaging-activemq/server=default/path=journal-directory:read-resource
{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/journal",
        "relative-to" => "jboss.server.data.dir"
    }
}

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=path,value=PATH_LOCATION)

/subsystem=messaging-activemq/server=default/path=journal-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

/subsystem=messaging-activemq/server=default:write-attribute(name=create-journal-dir,value=TRUE/FALSE)

/subsystem=messaging-activemq/server=default:read-attribute(name=ATTRIBUTE_NAME)

/subsystem=messaging-activemq/server=default:write-attribute(name=ATTRIBUTE_NAME,value=NEW_VALUE)

您可以将 JBoss EAP 7 消息传递配置为使用 JDBC 将消息持久化并绑定至数据库，而不使用默认的基于文件的日志。为此，您必须首先在 datasource s 子系统中配置数据源元素，然后在 messaging - activemq 子系统中的 server 元素上定义 journal- datasource 属性来使用该数据源。存在 journal-datasource 属性通知 messaging 子系统将日志条目持久保存到数据库，而非基于文件的日志。messaging - activemq 子系统中 server 资源的 journal- database 属性定义用于与数据库通信的 SQL dialect。它使用数据源元数据自动配置。

当将消息永久保留到基于文件的日志时，较大的消息大小仅受磁盘大小的限制。但是，当持久保留消息到数据库时，较大的消息大小仅限于该数据库的 BLOB 数据类型的最大大小。

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-page-store-table,value="\"PAGE_DATA\"")

<server name="default">
  <journal datasource="MessagingOracle12cDS" journal-page-store-table="&quot;PAGED_DATA&quot;"/>
  ...
</server>

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-page-store-table,value="${env.NODE_ID}_page_store")

data-source add --name=messaging-journal --jndi-name=java:jboss/datasources/messaging-journal --driver-name=oracle12c  --connection-url=${env.DB_CONNECTION_URL}

/subsystem=messaging-activemq/server=default:write-attribute(name=journal-jdbc-network-timeout,value=10000)

您可以使用以下管理 CLI 命令管理消息传递日志准备的事务：

在某些情况下，消息传递系统需要零持久性。零持久性意味着不应保留绑定数据、消息数据、大消息数据、重复 ID 缓存或分页数据。

若要配置 messaging-activemq 子系统来执行零持久性，请将 启用 persistence 的参数设置为 false。

/subsystem=messaging-activemq/server=default:write-attribute(name=persistence-enabled,value=false)

有关导入和导出日志数据的信息，请参阅 JBoss EAP 7 迁移指南。

JBoss EAP 消息传递支持许多消息队列，每个队列包含数百万条消息。JBoss EAP 消息传递服务器运行的内存有限，因此很难一次性将所有消息队列存储到内存中。

分页是 JBoss EAP 消息传递服务器用于按需透明地对内存中和内存不足的消息分页的机制，以便在有限内存中适应大型消息队列。

当特定地址的消息大小超过配置的最大消息大小时，JBoss EAP 消息传递开始分页到磁盘。

文件系统中的每个地址都有一个单独的文件夹，可将消息存储在多个文件中。存储消息的文件称为页面文件。每一文件包含的消息最多由 page-size-bytes 属性设置的最大配置的消息大小。

系统根据需要导航页面文件，并在页面中的所有消息都由客户端收到后立即删除页面文件。

您可以使用下面的管理 CLI 命令读取分页目录的配置。在本例中，输出中显示默认配置。

/subsystem=messaging-activemq/server=default/path=paging-directory:read-resource
{
    "outcome" => "success",
    "result" => {
        "path" => "activemq/paging",
        "relative-to" => "jboss.server.data.dir"
    }
}

分 页目录 配置元素指定要存储页面文件的文件系统中的位置。JBoss EAP 为此分页目录中的每个分页地址创建一个文件夹，页面文件则存储在这些文件夹中。默认情况下，此路径为 activemq/paging/。您可以使用以下管理 CLI 命令更改路径位置：

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=path,value=PATH_LOCATION)

另请注意上述示例输出中的 relative-to 属性。指定 relative-to 时，path 属性的值被视为 relative-to 属性指定的文件路径的相对。默认情况下，这个值是 JBoss EAP jboss.server.data.dir 属性。对于单机服务器，jboss.server.data.dir 位于 EAP_HOME/standalone/data/。对于受管域，每一服务器将拥有自己的 serverX/data/activemq/ 目录，位于 EAP_HOME/domain/servers/ 下。您可以使用以下管理 CLI 命令更改 relative-to 的值：

/subsystem=messaging-activemq/server=default/path=paging-directory:write-attribute(name=relative-to,value=RELATIVE_LOCATION)

当发送到地址的消息超过配置的大小时，该地址将进入分页模式。

即使使用 页面 模式，服务器也可能会因为内存不足而崩溃。JBoss EAP 消息传递保留对磁盘上每个页面文件的引用。在有数百万页面文件的情况下，JBoss EAP 消息传递可能会面临内存耗尽的情况。要最小化此风险，务必要将属性 page-size-bytes 设置为适当的值。您必须将 JBoss EAP 消息传递服务器的内存配置为目标数量为 max-size-bytes 的两倍，否则可能会出现内存不足错误。

您可以使用以下管理 CLI 命令，为地址读取当前的最大字节大小（最大字节数）：

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:read-attribute(name=max-size-bytes)

您可以使用以下管理 CLI 命令，为地址配置最大字节大小（最大字节数）。

/subsystem=messaging-activemq/server=default/address-setting=ADDRESS_SETTING:write-attribute(name=max-size-bytes,value=MAX_SIZE)

在读取或写入地址设置的其他分页相关属性的值时，请使用类似语法。下表列出了各个属性，以及描述和默认值。

下表描述了地址设置中的参数：

使用多个队列的地址

当消息路由到绑定有多个队列的地址时，内存中仅有一个消息副本。每个队列仅处理对该消息的原始副本的引用，因此仅当引用原始消息的所有队列都发送消息时，内存才会被释放。

如果您以标准方式发送大信息，发送它们所需的堆大小可以是消息大小的四倍或多倍，这意味着 1 GB 的消息可能需要 4 GB 的堆内存中。因此，JBoss EAP 消息传递支持使用 java.io. InputStream 和 java.io.OutputStream 类设置消息正文，它们需要的内存要少得多。输入流直接用于发送消息，输出流用于接收消息。

在接收信息时，可以通过两种方式处理输出流：

您可以使用您喜欢的任何流，例如文件 JDBC Blobs 或 SocketInputStream，只要它实施 java.io.InputStream 来 发送消息，而 java.io.OutputStream 用于接收消息。

使用核心 API 流传输大型消息

下表显示了使用对象属性通过 JMS 提供的 ClientMessage 类上的方法：

以下代码示例在接收核心消息时设置输出流。

ClientMessage firstMessage = consumer.receive(...);

// Block until the stream is transferred
firstMessage.saveOutputStream(firstOutputStream);

ClientMessage secondMessage = consumer.receive(...);

// Do not wait for the transfer to finish
secondMessage.setOutputStream(secondOutputStream);

以下代码示例在发送内核信息时设置输入流：

ClientMessage clientMessage = session.createMessage();
clientMessage.setInputStream(dataInputStream);

JMS 流传输大型消息

使用 JMS 时，JBoss EAP 消息传递通过设置对象属性来映射核心 API 流方法。您可以使用 Message.setObjectProperty(String name, Object value) 方法来设置输入和输出流。

在发送的消息上 ，使用 JMS_AMQ_InputStream 属性来设置 Input Stream。

BytesMessage bytesMessage = session.createBytesMessage();
FileInputStream fileInputStream = new FileInputStream(fileInput);
BufferedInputStream bufferedInput = new BufferedInputStream(fileInputStream);
bytesMessage.setObjectProperty("JMS_AMQ_InputStream", bufferedInput);
someProducer.send(bytesMessage);

OutputStream 使用 JMS_AMQ_SaveStream 属性来设置，对以阻止方式接收的消息使用 JMS_AMQ_SaveStream 属性。

BytesMessage messageReceived = (BytesMessage) messageConsumer.receive(120000);
File outputFile = new File("huge_message_received.dat");
FileOutputStream fileOutputStream = new FileOutputStream(outputFile);
BufferedOutputStream bufferedOutput = new BufferedOutputStream(fileOutputStream);

// This will block until the entire content is saved on disk
messageReceived.setObjectProperty("JMS_AMQ_SaveStream", bufferedOutput);

也可以通过使用 JMS_AMQ_Output Stream 属性以非阻塞方式设置 Output Stream。

// This does not wait for the stream to finish. You must keep the consumer active.
messageReceived.setObjectProperty("JMS_AMQ_OutputStream", bufferedOutput);

您可以通过设置到期地址来指定发送过期消息的位置。如果消息过期且未指定到期地址，则消息将从队列中删除并丢弃。

您可以使用管理 CLI 为 address -setting 设置 expiration-address。在以下示例中，jms.queue.exampleQueue 队列中的过期消息将发送到 jms.queue.expiryQueue 到期地址。

/subsystem=messaging-activemq/server=default/address-setting=jms.queue.exampleQueue:write-attribute(name=expiry-address,value=jms.queue.expiryQueue)

恢复器线程定期检查队列，以检查消息是否已过期。您可以使用管理 CLI 为回收器线程设置扫描周期和线程优先级。

设置到期恢复器线程的扫描周期，也就是以毫秒为单位扫描队列的频率，以检测过期的消息。默认值为 30000。您可以将其设置为 -1，以禁用回收器线程。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-scan-period,value=30000)

设置到期的线程优先级。可能的值从 0 到 9，其中 9 是最高优先级。默认值为 3。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-expiry-thread-priority,value=3)

JBoss EAP 消息传递包括的配置，用于定义预先为使用者获取的数据量，以及控制使用者能够使用消息的速度。

基于窗口的流控制

JBoss EAP 消息预先填充到每位消费者的缓冲区中。缓冲区的大小由 connection- factory 的 consumer-window- size 属性决定。以下示例配置显示了一个明确设置了 consumer- window-size 属性的 connection- factory。

<connection-factory name="MyConnFactory" ... consumer-window-size="1048576" />

使用管理 CLI，读取和写入给定 connection -factory 的 consumer-window- size 属性的值。以下示例演示了如何使用 InVmConnectionFactory 连接工厂完成此操作，对于驻留在同一虚拟机（例如本地 MessageDrivenBean ）的消费者而言，这是默认设置。

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-window-size)
{
    "outcome" => "success",
    "result" => 1048576
}

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-window-size,value=1048576)
{"outcome" => "success"}

consumer-window-size 的值必须是整数。下表中指出一些值具有特殊含义。

如果您使用核心 API，则使用者窗口大小可以使用其 setConsumerWindowSize（） 方法从 ServerLocator 设置。

如果您使用 JMS，客户端可以使用实例化 ConnectionFactory 的 setConsumerWindowSize（） 方法指定使用者窗口大小。

速率限制流控制

JBoss EAP 消息传递可以规范每秒使用的消息速率，这种流控制方法称为节流。使用适当 connection-factory 的 consumer-max- rate 属性，确保使用者不会以比指定的速度更快地使用消息。

<connection-factory name="MyConnFactory" ... consumer-max-rate="10" />

默认值为 -1，它会 禁用速率限制流控制。

管理 CLI 是读取和写入 consumer-max-rate 属性的建议方法。以下示例演示了如何使用 InVmConnectionFactory 连接工厂完成此操作，这对于驻留在同一虚拟机（例如本地 MessageDrivenBean ）的消费者而言是默认设置。

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:read-attribute(name=consumer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}

/subsystem=messaging-activemq/server=default/connection-factory=InVmConnectionFactory:write-attribute(name=consumer-max-rate,value=100)
{"outcome" => "success"}

如果使用 JMS，可使用实例化 ConnectionFactory 的 setConsumerMaxRate(int consumerMaxRate)方法设置最大速率大小。

如果您使用 Core API，可使用 ServerLocator.setConsumerMaxRate(int consumerMaxRate) 方法设置速率。

JBoss EAP 消息传递还可以限制从客户端发送的数据量，以防止服务器接收过多的消息。

基于窗口的流控制

JBoss EAP 消息传递利用信用交换规范消息制作者。只要有足够的学分，生产者就可以发送消息到地址。发送邮件所需的信用金额由邮件大小决定。由于生产者的学分较低，他们必须从服务器请求更多。在服务器配置中，生产者一次请求的信用量称为 producer-window-size，这是 connection-factory 元素的属性：

<connection-factory name="MyConnFactory" ... producer-window-size="1048576" />

窗口大小决定了任意时间可以内亮的字节数量，从而防止远程连接过载服务器。

使用管理 CLI 读取和写入给定连接工厂的 producer-window-size 属性。以下示例使用 RemoteConnectionFactory，它包含在默认配置中并供远程客户端使用。

subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-window-size)
{
    "outcome" => "success",
    "result" => 65536
}

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-window-size,value=65536)
{"outcome" => "success"}

如果您使用 JMS，客户端可以调用 ConnectionFactory 的 setProducerWindowSize(int producerWindowSize) 方法来直接设置窗口大小。

如果使用 core API，可以使用 ServerLocator 的 setProducerWindowSize(int producerWindowSize) 方法设置窗口大小。

阻塞基于 Producer Window 的流控制

通常，消息传递服务器始终提供与请求相同的分数。但是，可以限制服务器发送的信用量，这可以防止因为生产者发送超过一次可处理的消息而耗尽内存。

例如，如果您有一个名为 myqueue 的 JMS 队列，并且您将最大内存大小设置为 10MB，服务器将规定队列中的消息数量，使其大小永不会超过 10MB。当地址变满时，生产者将在客户端阻止，直到地址上有足够的空间可用。

address-setting 配置元素包含用于管理阻止制作者流控制的配置。address-setting 用于将一组配置应用到该地址注册的所有队列。有关如何进行此操作的更多信息，请参阅配置地址设置。

对于需要阻止制作者流控制的每个 address-setting，您必须包含 max-size-bytes 属性的值。绑定到该地址的所有队列的总内存不能超过 max-size-bytes。如果是 JMS 主题，这意味着主题中所有订阅的总内存不能超过 max-size-bytes。

您还必须将 address-full-policy 属性设置为 BLOCK，以便服务器知道如果达到 max-size-bytes， 则应阻止制作者。以下是设置了这两个属性 的 address-setting 示例：

<address-setting ...
      name="myqueue"
      address-full-policy="BLOCK"
      max-size-bytes="100000" />

上例会将 JMS 队列"myqueue"的最大大小设置为 100000 字节。达到最大大小后，生产者将被阻止发送到该地址。

使用管理 CLI 设置这些属性，如下例所示：

/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=max-size-bytes,value=100000)
{"outcome" => "success"}

/subsystem=messaging-activemq/server=default/address-setting=myqueue:write-attribute(name=address-full-policy,value=BLOCK)
{"outcome" => "success"}

速率限制流控制

如果您为它所使用的 connection-factory 指定制作者/最大值，请限制生产者 每秒可发送的消息数量，如下例所示：

<connection-factory name="MyConnFactory" producer-max-rate="1000" />

默认值为 -1，它会 禁用速率限制流控制。

使用管理 CLI 读取和写入 producer-max-rate 的值。以下示例使用 RemoteConnectionFactory，它包含在默认配置中并供远程客户端使用。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-attribute(name=producer-max-rate)
{
    "outcome" => "success",
    "result" => -1
}

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=producer-max-rate,value=100)
{"outcome" => "success"}

如果使用 core API，请使用方法 ServerLocator.setProducerMaxRate(int producerMaxRate) 来设置速率。

如果您使用 JNDI 来实例化和查找连接工厂，则可以使用实例化连接工厂的 setProducerMaxRate(int producerMaxRate) 方法在客户端上设置最大速率。

可以使用管理 CLI 将预确认 属性设置为 true，从而将连接工厂配置为使用预 确认模式：

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=pre-acknowledge,value=true)

预确认模式可以在客户端的 JNDI 上下文环境中配置，例如在 jndi.properties 文件中：

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?preAcknowledge=true

另外，也可通过 JMS API 使用预确认模式，创建一个带有 ActiveMQSession.PRE_ACKNOWLEDGE 常量的 JMS 会话。

// messages will be acknowledge on the server *before* being delivered to the client
Session session = connection.createSession(false, ActiveMQJMSConstants.PRE_ACKNOWLEDGE);

拦截器必须实现拦截器接口：

package org.apache.artemis.activemq.api.core.interceptor;

public interface Interceptor
{
   boolean intercept(Packet packet, RemotingConnection connection) throws ActiveMQException;
}

返回的布尔值很重要：

拦截器类应作为模块添加到 JBoss EAP 中。如需更多信息，请参阅 JBoss EAP 配置指南中的 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html-single/configuration_guide/#create_a_custom_module 创建自定义模块。

在将模块添加到 JBoss EAP 作为自定义模块后，传入和传出拦截器都通过管理 CLI 添加到消息传递子系统配置中。

每个拦截器都应该根据以下示例管理 CLI 命令添加。示例假定每个拦截器已作为自定义模块添加到 JBoss EAP 中。

/subsystem=messaging-activemq/server=default:list-add(name=incoming-interceptors, value={name => "foo.bar.MyIncomingInterceptor", module=>"foo.bar.interceptors"})

添加传出拦截器遵循类似语法，如下例所示：

/subsystem=messaging-activemq/server=default:list-add(name=outgoing-interceptors, value={name => "foo.bar.MyOutgoingInterceptor", module=>"foo.bar.interceptors"})

属性 _AMQ_GROUP_ID 用于使用客户端端的核心 API 标识消息组。要选择随机的唯一消息组标识符，您可以在 SessionFactory 上将 auto-group 属性设置为 true。

属性 JMSXGroupID 用于标识 Java 消息服务(JMS)客户端的消息组。如果您要向一个消费者发送具有不同消息的消息组，您可以为不同的消息设置相同的 JMSXGroupID。

Message message = ...
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);

message = ...
message.setStringProperty("JMSXGroupID", "Group-0");
producer.send(message);

另一种方法是使用下列 connection-factory 属性之一供客户端使用： auto-group 或 group-id。

当 auto-group 设为 true 时，connection-factory 将开始对通过它发送的所有消息使用随机唯一的消息组标识符。您可以使用管理 CLI 来设置 auto-group 属性。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=auto-group,value=true)

group-id 属性会将属性 JMSXGroupID 设置为通过连接工厂发送的所有消息的指定值。要在连接工厂上设置特定的 group-id，请使用管理 CLI。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=group-id,value="Group-0")

以下是在配置中可能出现排他性的问题示例：

<divert
  name="prices-divert"
  address="jms.topic.priceUpdates"
  forwarding-address="jms.queue.priceForwarding"
  filter="office='New York'"
  transformer-class-name="org.apache.activemq.artemis.jms.example.AddForwardingTimeTransformer"
  exclusive="true"/>

在本例中，配置了一个名为 price -divert 的转换，它将丢弃发送到 address jms.topic. priceUpdates 的所有消息，它将映射到发送到名为 price Updates 的 JMS 主题的任何消息， 到另一个本地地址 jms.queue. priceForwarding，对应于名为 priceForwarding 的本地 JMS队列。

我们还指定消息过滤器字符串，以便仅 丢弃 值为 New York 的消息。所有其他消息将继续路由到正常地址。若未指定，过滤器字符串为可选，则所有消息都将被视为匹配项。

请注意，指定了转换器类。在这个示例中，转换器只是添加一个标头来记录发生移动的时间。

此示例实际将消息转移到本地存储和转发队列，该队列配置了将消息转发到另一服务器上的地址的网桥。如需了解更多详细信息，请参阅配置核心网桥。

以下是非排他性转变的示例。非排他性转移的配置方式与使用可选的过滤器和转换器独占式转换法相同。

<divert
  name="order-divert"
  address="jms.queue.orders"
  forwarding-address="jms.topic.spytopic"
  exclusive="false"/>

以上转换采用发送到 address jms.queue.orders 的每个消息的副本，该副本映射到名为 Order 的 JMS 队列 ， 并将其发送到名为 jms.topic.SpyTopic 的本地地址。SpyTopic 对应于名为 SpyTopic 的 JMS 主题。

创建转变

使用管理 CLI 创建您想要的转变类型：

/subsystem=messaging-activemq/server=default/divert=my-divert:add(divert-address=news.in,forwarding-address=news.forward)

默认情况下会创建非排他性转换。要创建专用转变，请使用 exclusive 属性：

/subsystem=messaging-activemq/server=default/divert=my-exclusive-divert:add(divert-address=news.in,forwarding-address=news.forward,exclusive=true)

下表捕获了转换的属性及其描述。您可以使用以下命令显示管理 CLI：

/subsystem=messaging-activemq/server=default/divert=*:read-resource-description()

服务器调度线程池用于需要定期运行或有延迟的服务器端的大部分活动。它在内部映射到 java.util.concurrent.ScheduledThreadPoolExecutor 实例。

此池使用的最大线程数通过使用 scheduled-thread-pool-max-size 参数来 配置。默认值为 5 个线程。通常，少量线程足以满足这个池的需要。要为默认的 JBoss EAP 消息传递服务器更改此值，请使用以下命令：

/subsystem=messaging-activemq/server=default:write-attribute(name=scheduled-thread-pool-max-size,value=10)

线程池通常用于服务器端的大部分异步操作。它在内部映射到 java.util.concurrent.ThreadPoolExecutor 实例。

此池使用的最大线程数通过使用 thread-pool-max-size 属性来配置。

如果将 thread-pool-max-size 设为 -1，则线程池没有上限，并在没有足够的线程来满足请求时按需创建新的线程。如果稍后的活动细分，则线程超时并关闭。

如果将 thread-pool-max-size 设置为大于零的正整数，则线程池将被绑定。如果请求进入并且池中没有可用线程，请求将停止，直到线程可用为止。建议谨慎使用有界线程池，因为如果上限配置过低，可能会导致死锁情况。

thread-pool-max-size 的默认值为 30。若要为默认的 JBoss EAP 消息传递服务器设置一个新值，可使用以下管理 CLI 命令：

/subsystem=messaging-activemq/server=default:write-attribute(name=thread-pool-max-size,value=40)

如需有关未绑定(cached)和绑定（固定）线程池的更多信息，请参阅 ThreadPoolExecutor Javadoc。

检查线程利用率，以确保您已正确配置线程池的大小。

要检查线程使用率，请发出以下 CLI 命令：

/subsystem=messaging-activemq:read-resource(include-runtime)

系统返回的结果类似如下

{
    "outcome" => "success",
    "result" => {
        "global-client-scheduled-thread-pool-active-count" => 0,
        "global-client-scheduled-thread-pool-completed-task-count" => 0L,
        "global-client-scheduled-thread-pool-current-thread-count" => 0,
        "global-client-scheduled-thread-pool-keepalive-time" => 10000000L,
        "global-client-scheduled-thread-pool-largest-thread-count" => 0,
        "global-client-scheduled-thread-pool-max-size" => undefined,
        "global-client-scheduled-thread-pool-task-count" => 0L,
        "global-client-thread-pool-active-count" => 0,
        "global-client-thread-pool-completed-task-count" => 2L,
        "global-client-thread-pool-current-thread-count" => 2,
        "global-client-thread-pool-keepalive-time" => 60000000000L,
        "global-client-thread-pool-largest-thread-count" => 2,
        "global-client-thread-pool-max-size" => undefined,
        "global-client-thread-pool-task-count" => 2L,
        "connection-factory" => undefined,
        "connector" => undefined,
        "discovery-group" => undefined,
        "external-jms-queue" => undefined,
        "external-jms-topic" => undefined,
        "http-connector" => undefined,
        "in-vm-connector" => undefined,
        "jms-bridge" => undefined,
        "pooled-connection-factory" => undefined,
        "remote-connector" => undefined,
        "server" => {"default" => undefined}
    }
}

在服务器端也使用一个线程扫描队列中过期的消息。我们无法为此使用任一线程池，因为此线程需要以自己的可配置优先级运行。

异步 IO 有一个线程池，用于从原生层接收和分配事件。它位于带有前缀 ArtemisMQ-AIO-poller-pool 的线程转储中。JBoss EAP 消息传递在日志中为每个打开的文件使用一个线程（通常为一个线程）。

还有一个线程用于在 libaio 上调用写入。其目的在于避免在 libaio 上切换会导致性能问题。此线程可在带有前缀 ArtemisMQ-AIO-writer-pool 的线程转储中找到。

JBoss EAP 包括用于创建客户端连接的客户端线程池。这个池与本章前面提到的静态池分开，在 JBoss EAP 的行为类似于客户端时使用它。例如，客户端线程池客户端作为与同一集群中其他节点的群集连接创建，或者当 Artemis 资源适配器连接到集成于 JBoss EAP 远程实例的远程 Apache ActiveMQ Artemis 消息传递服务器时。还有一个用于调度的客户端线程的池。

使用管理 CLI 设置客户端线程池大小

使用管理 CLI 配置客户端线程池和客户端调度线程池的大小。使用管理 CLI 设置的池大小优先于使用系统属性设置的大小。

以下命令设置客户端线程池。

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=POOL_SIZE)

此属性没有定义默认值。如果未定义 属性，则池的最大大小确定为 CPU 内核处理器的八(8)倍。

若要查看当前的设置，可使用以下命令：

/subsystem=messaging-activemq:read-attribute(name=global-client-thread-pool-max-size)

使用以下命令设置客户端计划线程池大小：

/subsystem=messaging-activemq:write-attribute(name=global-client-scheduled-thread-pool-max-size,value=POOL_SIZE)

以下将显示客户端计划线程池的当前池大小：默认值为 5。

/subsystem=messaging-activemq:read-attribute(name=global-client-scheduled-thread-pool-max-size)

使用系统属性设置客户端线程池大小

以下系统属性可用于分别设置客户端的全局和全局调度线程池的大小：

然后，可以在 XML 配置中引用系统属性，如下例所示。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <global-client thread-pool-max-size="${activemq.artemis.client.global.thread.pool.max.size}"
    scheduled-thread-pool-max-size="${activemq.artemis.client.global.scheduled.thread.pool.core.size}" />
  <server ...>
  </server>
  ...
</subsystem>

配置客户端以使用其拥有的线程池

客户端可以配置其每个 ClientSessionFactory 实例，使其不使用 JBoss EAP 提供的池，而是使用自己的客户端线程池。从该 客户端SessionFactory 创建的任何会话都将使用新创建的池。

要将 ClientSessionFactory 实例配置为使用其自己的池，请在创建工厂后立即调用适当的 setter 方法。例如：

ServerLocator locator = ActiveMQClient.createServerLocatorWithoutHA(transportConfiguration);
locator.setUseGlobalPools(true);
locator.setThreadPoolMaxSize(-1);
locator.setScheduledThreadPoolMaxSize(10);
ClientSessionFactory myFactory = locator.createSessionFactory();

如果使用 JMS API，您可以在 ClientSessionFactory 上设置相同的参数。例如：

ActiveMQConnectionFactory myConnectionFactory = ActiveMQJMSClient.createConnectionFactory(url, "ConnectionFactoryName");
myConnectionFactory.setUseGlobalPools(false);
myConnectionFactory.setScheduledThreadPoolMaxSize(10);
myConnectionFactory.setThreadPoolMaxSize(-1);

如果您使用 JNDI 来实例化 ActiveMQConnectionFactory 实例，您也可以使用管理 CLI 来设置这些参数，如下例所示，适用于 JBoss EAP 单机实例。

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=use-global-pools,value=false)

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=scheduled-thread-pool-max-size,value=10)

/subsystem=messaging-activemq/server=default/connection-factory=myConnectionFactory:write-attribute(name=thread-pool-max-size,value=1)

请注意，管理 CLI 将提醒您在执行上述每个命令后需要重新加载实例。

要为发送的消息启用重复的消息检测，您需要将 org.apache.activemq.artemis.api.core.Message.HDR_DUPLICATE_DETECTION_ID 属性的值解析为 _AMQ_DUPL_ID 属性。当目标服务器收到消息时，如果设置了 _AMQ_DUPL_ID 属性，它将检查其内存缓存，以查看它是否收到了具有该标头值的消息。如果存在，则忽略此消息。如需更多信息，请参阅配置重复 ID 缓存。

如果您使用核心 API，_AMQ_DUPL_ID 属性的值可以是 字节[] 或 SimpleString。如果您使用 JMS，它必须是一个 字符串。

以下示例演示了如何为核心 API 设置 属性。

SimpleString myUniqueID = "This is my unique id";   // Can use a UUID for this

ClientMessage message = session.createMessage(true);
message.setStringProperty(HDR_DUPLICATE_DETECTION_ID, myUniqueID);

下例演示了如何为 JMS 客户端设置 属性。

String myUniqueID = "This is my unique id";   // Can use a UUID for this

Message jmsMessage = session.createMessage();
message.setStringProperty(HDR_DUPLICATE_DETECTION_ID.toString(), myUniqueID);

服务器维护发送到每个地址的 _AMQ_DUPL_ID 属性的接收值缓存。每个地址维护自己的地址缓存。

缓存的大小是固定的。缓存的最大大小使用 id-cache-size 属性来配置。此参数的默认值为 20000 元素。如果缓存的最大值为 n 个元素，则存储的(n + 1)thID 将覆盖缓存中的元素 0。该值使用以下管理 CLI 命令设置：

/subsystem=messaging-activemq/server=default:write-attribute(name=id-cache-size,value=SIZE)

缓存也可以配置为永久保留到磁盘。这可以通过使用以下命令设置 persist-id-cache 属性来配置：

/subsystem=messaging-activemq/server=default:write-attribute(name=persist-id-cache,value=true)

如果此值设为 true，则每个 ID 在收到时都会保留为永久存储。此参数的默认值为 true。

在 JBoss EAP 中，服务质量是一种 可配置的属性，决定了消息的使用和确认方式。服务质量及其 描述的有效值如下所示。有关 JMS 网桥属性的完整列表，请参见附录中的 表。

通过使用 DUPLICATES_OK 模式而不是 ONCE_AND_ ONLY_ONCE，然后检查目的地是否有重复项并丢弃它们，可以提供一次且仅一次的语义。如需更多信息，请参阅配置重复消息检测。但是，缓存仅在一定时间内有效。因此，这种方法不再像使用 ONCE_AND_ONLY_ONCE 一样好，但根据您的特定应用需求，这可能是一个不错的选择。

目标或源服务器可能在特定时间点上不可用。如果出现这种情况，网桥将尝试重新连接等于 max-retries 值的多次。尝试之间的等待通过 failure-retry-interval 设置。

如果消息中还没有一个，则核心网桥可以自动添加唯一的重复 ID 值，然后再将消息转发到目标。若要为重复消息检测配置核心网桥，可将 use-duplicate-detection 属性 设为 true，这是默认值。

/subsystem=messaging-activemq/server=default/bridge=my-core-bridge:write-attribute(name=use-duplicate-detection,value=true)

服务器发现是一种机制，服务器可以通过这个机制将其连接详情传播到：

此信息或群集拓扑围绕通过群集连接与客户端和其他服务器的正常 JBoss EAP 消息传递连接发送。但是，您需要一种方法来建立初始第一个连接。这可以通过 UDP 和 JGroups 等动态发现技术或提供初始连接器的静态列表来实现。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <broadcast-group name="my-broadcast-group" connectors="http-connector" socket-binding="messaging-group"/>
    ...
  </server>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  ...
  <socket-binding name="messaging-group" interface="private" port="5432" multicast-address="231.7.7.7" multicast-port="9876"/>
  ...
</socket-binding-group>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <broadcast-group name="my-broadcast-group" connectors="http-connector" jgroups-cluster="activemq-cluster"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default/broadcast-group=my-broadcast-group:add(connectors=[http-connector],jgroups-cluster=activemq-cluster)

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <discovery-group name="my-discovery-group" refresh-timeout="10000" socket-binding="messaging-group"/>
    ...
  </server>
</subsystem>
...
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
  ...
  <socket-binding name="messaging-group" interface="private" port="5432" multicast-address="231.7.7.7" multicast-port="9876"/>
  ...
</socket-binding-group>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <discovery-group name="my-discovery-group" refresh-timeout="10000" jgroups-cluster="activemq-cluster"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default/discovery-group=my-discovery-group:add(refresh-timeout=10000,jgroups-cluster=activemq-cluster)

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <connection-factory name="RemoteConnectionFactory" entries="java:jboss/exported/jms/RemoteConnectionFactory" connectors="http-connector"/>
    ...
  </server>
</subsystem>

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <pooled-connection-factory name="activemq-ra" transaction="xa" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm"/>
    ...
  </server>
</subsystem>

final String groupAddress = "231.7.7.7";
final int groupPort = 9876;

ServerLocator factory =
  ActiveMQClient.createServerLocatorWithHA(new DiscoveryGroupConfiguration(
      groupAddress,
      groupPort,
      new UDPBroadcastGroupConfiguration(groupAddress, groupPort, null, -1)));
ClientSessionFactory factory = locator.createSessionFactory();
ClientSession session1 = factory.createSession();
ClientSession session2 = factory.createSession();

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <connection-factory name="MyConnectionFactory" entries="..." connectors="http-connector http-node1 http-node2"/>
    ...
  </server>
</subsystem>

HashMap<String, Object> map = new HashMap<String, Object>();
map.put("host", "myhost");
map.put("port", "8080");

HashMap<String, Object> map2 = new HashMap<String, Object>();
map2.put("host", "myhost2");
map2.put("port", "8080");

TransportConfiguration server1 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map);
TransportConfiguration server2 = new TransportConfiguration(NettyConnectorFactory.class.getName(), map2);

ServerLocator locator = ActiveMQClient.createServerLocatorWithHA(server1, server2);
ClientSessionFactory factory = locator.createSessionFactory();
ClientSession session = factory.createSession();

如果在群集的节点之间定义了群集连接，则 JBoss EAP 消息传递将对客户端到达特定节点的消息进行负载平衡。

消息传递集群连接可以配置为以轮循方式对消息进行负载平衡，无论其他节点上是否存在匹配的使用者。也可以将其配置为仅在存在匹配的消费者时分发到其他节点。如需更多信息，请参阅 Message Redistribution 部分。

配置集群连接

群集连接将服务器分组到集群中，以便在群集的节点之间平衡消息。群集连接在 JBoss EAP 服务器配置中利用 cluster-connection 元素定义。

以下是 * -full 和 *-full- ha 配置集中定义的默认 cluster- connection。如需完整的属性列表，请参阅群集连接属性。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster-connection name="my-cluster" discovery-group="dg-group1" connector-name="http-connector" address="jms"/>
    ...
  </server>
</subsystem>

在上面显示的情况下，集群连接将加载发送到以"jms"开头的地址的消息负载平衡。实际上，此群集连接将应用到所有 JMS 队列和主题，因为它们映射到以子字符串"jms"开头的核心队列。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster-connection name="my-cluster" static-connectors="server0-connector server1-connector" .../>
    ...
  </server>
</subsystem>

为重复数据删除配置集群连接

集群连接内部使用核心网桥在集群节点之间移动消息。若要为重复的消息检测配置集群连接，请将 use-duplicate-detection 属性 设置为 true，这是默认值。

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:write-attribute(name=use-duplicate-detection,value=true)

集群用户凭证

在集群节点之间创建连接以组成群集连接时，JBoss EAP 消息使用群集用户和密码。

您可以使用以下管理 CLI 命令来设置集群用户和密码。

/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-user,value="NewClusterUser")
/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-password,value="NewClusterPassword123")

这会将下列 XML 内容添加到 JBoss EAP 配置文件中的 messaging-activemq 子系统：

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <cluster user="NewClusterUser" password="NewClusterPassword123"/>
    ...
  </server>
</subsystem>

/subsystem=messaging-activemq/server=default:write-attribute(name=cluster-credential-reference,value={clear-text=SecretStorePassword})

借助 JBoss EAP 消息客户端负载平衡，使用单一会话工厂创建的后续会话可以连接到群集的不同节点。这允许会话在群集的节点间均匀分布，而不会在任何特定节点上断开。

声明客户端工厂使用的负载平衡策略的建议方法是设置 <connection -factory> 资源的 connection-load-balancing-policy- class-name 属性。JBoss EAP 消息传递提供下列出厂负载平衡策略，您也可以自行实施：

您还可以通过实施接口 org.apache.activemq.artemis.api.core.client.loadbalance.ConnectionLoadBalancingPolicy来实施自己的策略

通过消息重新发布，JBoss EAP 消息传递可以配置为从队列自动重新分发消息，这些队列中没有任何使用者返回到群集中具有匹配使用者的其他节点。要启用此功能，集群连接的 message-load-balancing-type 必须设置为 ON_DEMAND，这是默认值。您可以使用以下管理 CLI 命令设置此项：

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:write-attribute(name=message-load-balancing-type,value=ON_DEMAND)

可以将消息重新分发配置为在队列上的最后一个使用者关闭后立即启动，或者在队列上的最后一个使用者关闭后等待可配置的延迟再分发。这使用 reload -delay 属性进行配置。

您可以使用 重新发布-delay 属性设置在队列中最后一个消费者关闭后等待多少毫秒，然后再将来自该队列的消息重新分发到群集中匹配消费者的其他节点。值为 -1 （默认值）表示永远不会重新分发消息。值 0 表示将立即重新分发消息。

默认 JBoss EAP 配置中的 address-setting 设置 re istribute-delay 值 1000，这意味着它将等待 1000 毫秒后再分发消息。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <address-setting name="#" redistribution-delay="1000" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
    ...
  </server>
</subsystem>

在重新分发之前引入延迟通常比较适当，因为消费者关闭，但在同一队列中快速创建另一个延迟的情况通常比较适当。在这种情况下，您可能不想立即重新分发，因为新消费者很快会到达。

以下是 address-setting 的示例，它为绑定到 以"jms"开头的地址的任何队列或主题设置重新分配-delay 0。在这种情况下，消息将立即重新分发。

<subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0">
  <server name="default">
    ...
    <address-setting name="jms.#" redistribution-delay="0"/>
    ...
  </server>
</subsystem>

此地址设置可通过以下管理 CLI 命令添加：

/subsystem=messaging-activemq/server=default/address-setting=jms.#:add(redistribution-delay=1000)

群集分组遵循与正常消息分组相关的不同方法。在群集中，具有特定组 ID 的消息组可以到达任何节点。节点务必要确定哪些组 ID 绑定到哪个节点上哪个消费者。无论消息组默认到达何处，每个节点负责将消息组路由到拥有消费者处理这些组 ID 的节点。当带有给定组 id 的消息发送到连接到集群中给定节点的特定消费者后，即使消费者断开连接，这些消息也不会发送到另一个节点。

这种情形可通过分组处理程序来解决。每个节点都有一个分组处理程序，此分组处理程序（以及其他处理程序）负责将消息组路由到正确的节点。有两种类型的分组处理程序：LOC AL 和 REMOTE。

本地处理程序负责确定消息组应采用的路由。远程处理程序与本地处理程序通信，并相应地工作。每个群集应当选择具有本地分组处理程序的特定节点，所有其他节点都应具有远程处理程序。

最初收到消息组的节点根据常规集群路由条件（循环队列可用性）做出路由决定。节点向对应的分组处理程序提出此决定，后者将消息路由到建议队列（如果它接受该请求）。

如果分组处理程序拒绝该提议，它会提出其他路由，相应地进行路由。其他节点跟随 Suite，并将消息组转发到所选队列。消息到达队列中后，它将固定到该队列上的客户。

您可以使用管理 CLI 配置分组处理程序。以下命令添加带有地址 news.europe.# 的 LOCAL 分组处理程序。

/subsystem=messaging-activemq/server=default/grouping-handler=my-group-handler:add(grouping-handler-address="news.europe.#",type=LOCAL)

这将需要重新加载服务器。

reload

下表列出了 grouping -handler 的可配置 属性：

当您将 JBoss EAP 7.3 服务器配置为组成 ActiveMQ Artemis 集群时，可能还有其他服务器和客户端连接到正在运行的集群服务器。建议先关闭连接的客户端和服务器，然后再关闭群集中运行的 JBoss EAP 7.3 服务器。这必须按顺序执行，而不能并行执行，以便服务器有足够的时间关闭所有连接并避免在关闭可能会导致不一致状态时发生故障。ActiveMQ Artemis 不支持自动缩减群集节点，并且希望重新启动所有群集节点。

启动服务器时也是如此。您必须首先在 ActiveMQ Artemis 集群中启动 JBoss EAP 7.3 服务器。启动完成后，您可以启动其他连接到集群的服务器和客户端。

JBoss EAP 7 消息传递使得服务器能够作为实时链接在一起 - 每个现场服务器都有备份对备份对。实时服务器从客户端接收消息，而备份服务器在故障转移发生之前不运行。备份服务器只能归一台现场服务器所有，它将保持被动模式，等待实时服务器工作。

当实时服务器崩溃或进入正确的模式时，当前处于被动模式的备份服务器将成为新的实时服务器。如果新实时服务器配置为允许自动故障恢复，它将检测到旧的实时服务器重新启动并自动停止，从而使旧的实时服务器可以再次开始接收消息。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-attribute(name=synchronized-with-backup)

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:read-attribute(name=synchronized-with-live)

JBoss EAP 消息传递支持两种不同的策略来备份服务器：复制和共享存储。使用 服务器配置 元素的 ha-policy 属性，将您选择的策略分配给给定的服务器。ha-policy 有四个有效值：

如您所见，值指定服务器使用数据复制还是 共享存储 ha 策略，以及它是否取 master 还是 slave 角色。

使用管理 CLI 将 ha-policy 添加到您选择的服务器。

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:add

例如，使用以下命令将 replication-master 策略 添加到 默认 服务器：

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:add

replication-master 策略使用默认值进行配置。添加策略时，可以包含覆盖默认配置的值。管理 CLI 命令使用以下基本语法来读取当前配置：

/subsystem=messaging-activemq/server=SERVER/ha-policy=POLICY:read-resource

例如，使用以下命令来读取上方添加到 默认 服务器的 replication-master 策略的当前配置：也包含 输出以突出显示默认配置。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:read-resource

{
    "outcome" => "success",
    "result" => {
        "check-for-live-server" => true,
        "cluster-name" => undefined,
        "group-name" => undefined,
        "initial-replication-sync-timeout" => 30000L
    }
}

如需了解每个策略可用的配置选项的详细信息，请参阅数据复制和共享存储 。

在使用复制时，实时和备份服务器对不会共享相同的数据目录，所有数据同步都是通过网络进行的。因此，实时服务器接收的所有（永久）数据都将复制到备份中。

如果实时服务器已彻底关闭，备份服务器将激活，并且客户端将故障转移到备份。这个行为是预先确定的，因此在使用数据复制时不可配置。

备份服务器首先需要同步来自活动服务器的所有现有数据，然后才能进行替换。因此，与共享存储不同，副本备份在启动后不会立即完全运行。同步的发生时间取决于要同步的数据量和网络速度。另请注意，当备份启动时，客户端会在 初始复制-sync-timeout 期间被阻止。在此超时后，客户端将被取消阻塞，即使没有完成同步。

成功故障转移后，备份的日志将开始保存比实时服务器上的数据更新的数据。您可以将原始的实时服务器配置为执行故障恢复，并在重新启动后成为实时服务器。故障恢复将在实时服务器恢复在线之前同步备份与实时服务器之间的数据。

如果两个服务器都已关闭，管理员必须确定哪些服务器的日志具有最新的数据。如果备份日志具有最新的数据，请将该日志复制到实时服务器。否则，每当它再次激活时，备份将从实时服务器复制陈旧的日志数据并删除自己的日志数据。如果实时服务器的数据是最新数据，则不需要任何操作，并且可以正常启动服务器。

复制实时和备份对必须是集群的一部分。cluster-connection 配置元素定义备份服务器如何找到其实时匹配项。

复制至少需要三个实时/备份对，以减少网络隔离的风险，但您无法消除此风险。如果您使用至少三个 live/backup 对，集群可以使用仲裁投票来避免使用两个 live 代理。

配置 cluster-connection 时，请记住以下详情：

通过在 < master> 和 <slave> 元素中配置 group-name 属性来指定 一对 live/backup 服务器。备份服务器仅连接到共享同一 组名的实时服务器。

作为使用 group-name 的示例，假设您有三个实时服务器和三个备份服务器。因为每个实时服务器都必须带有自己的备份对，所以请分配以下组名称：

在本例中，服务器 backup1 会搜索具有相同 组名称对 1 的实时服务器，本例中为服务器 live1。

与共享存储案例中非常相似，当实时服务器停止或崩溃时，其复制和配对备份将变为活动状态并接管其职责。具体来说，配对备份将在丢失与其实时服务器的连接时激活。这可能有问题，因为可能会因为临时网络问题而发生。为解决这个问题，配对备份将尝试确定它是否仍然可以连接到群集中的其他服务器。如果它可以连接到超过一半的服务器，它将变为活动状态。如果无法与其实时服务器通信，并且群集中的其他服务器超过一半，配对备份将等待并尝试重新与实时服务器连接。这可降低"脑裂"情况的风险，即备份和实时服务器正在处理消息，而其他人不知道该情况。

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

/subsystem=messaging-activemq/server=default/ha-policy=replication-slave:write-attribute(name=restart-backup,value=true)

AMQ222207: The backup server is not responding promptly introducing latency beyond the limit. Replication server being disconnected now.

这种高可用性方式不同于数据复制，因为它需要可由实时和备份节点访问的共享文件系统。这意味着服务器对在其配置中使用相同的位置来分页、 消息日志、绑定日志和 大型消息。

此外，对中的每个参与服务器（实时和备份 ）也需要定义群集连接，即使不是群集的一部分，因为 群集连接 定义备份服务器如何将其存在声明到其实时服务器和其他任何节点。有关如何完成此操作的详情，请参阅配置集群连接。

发生故障转移并且备份服务器接管时，它将需要从共享文件系统加载持久存储，然后才能客户端连接它。这种高可用性方式不同于数据复制，因为它需要可由实时和备份对访问的共享文件系统。这通常是某种高性能存储区域网络或 SAN。红帽不推荐将网络附加存储（称为 NAS）用于您的存储解决方案。

共享存储高可用性的优势在于实时节点和备份节点之间不会发生复制，这意味着它不会因为正常操作期间复制的开销而受到性能偏差。

共享存储复制的缺点在于，当备份服务器激活它需要从共享存储加载日志时，这可能需要一些时间，具体取决于存储中的数据量。此外，它还需要 JBoss EAP 支持的共享存储解决方案。

如果您在正常操作过程中要求最高性能，红帽建议访问高性能 SAN，并接受稍慢的故障转移成本。确切的成本将取决于数据量。

/subsystem=messaging-activemq/server=default/ha-policy=POLICY:write-attribute(name=ATTRIBUTE,value=VALUE)

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=restart-backup,value=true)

在实时服务器出现故障并且备份接管了自己的职责后，您可能希望重新启动实时服务器，并让客户端恢复运行。

如果是共享存储，只需重新启动原先的实时服务器并通过终止进程本身终止新的实时服务器。或者，您可以在从 卷上将 allow-fail-back 设置为 true，它会强制其在主服务器恢复在线后自动停止。设置 allow-fail-back 的管理 CLI 命令类似如下：

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=allow-fail-back,value=true)

在复制 HA 模式中，您需要确保在主配置中 将 check-for-live-server 属性设置为 true。从 JBoss EAP 7.1 开始，这是默认值。

/subsystem=messaging-activemq/server=default/ha-policy=replication-master:write-attribute(name=check-for-live-server,value=true)

如果设置为 true，则 实时服务器将在启动过程中使用 nodeID 搜索另一个服务器。如果找到一个服务器，它将联系此服务器并尝试"失败"。由于这是一种远程复制方案，原始的实时服务器必须将其数据与运行的备份与其 ID 同步。同步后，它将请求备份服务器关闭，以便它可以接管活动的处理。此行为可让原始的实时服务器确定是否存在故障转移，如果发生故障，则承担其职责的服务器是否仍在运行。

对于共享存储，也可以在正常服务器关闭时导致故障转移发生，以便在主或从设备上的 HA 配置中将此 failover-on-server-shutdown 设置为 true ：

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=failover-on-server-shutdown,value=true)

您还可以强制运行的备份服务器在原始实时服务器恢复时关闭，从而允许原始的实时服务器自动接管，方法是将 allow-failback 设置为 true。

/subsystem=messaging-activemq/server=default/ha-policy=shared-store-slave:write-attribute(name=allow-failback,value=true)

JBoss EAP 还使得备份消息传递服务器可以和另一台实时服务器在同一 JVM 中并置。例如，一个简单的双节点单机服务器集群，每个实时服务器将备份一起分配给另一个服务器。在以这种方式接合服务器时，您可以使用共享存储或复制 HA 策略。在配置消息传递服务器进行并置时，需要记住两个重要事项。

首先，配置中的每个 server 元素都需要自己的 remote-connector 和 remote-acceptor 或 http-connector 和 http-acceptor。例如，具有 远程接收器的实时服务器可以 配置为侦听端口 5445，而 来自并置备份的远程 接收器则使用端口 5446。端口在 socket-binding 元素中定义，必须添加到默认的 socket-binding-group。如果是 http-acceptors，则实时和并置备份可以共享相同的 http-listener。每个服务器配置中与集群相关的配置元素将使用 服务器 使用的 remote-connector 或 http-connector。相关的配置包含在下面的每个示例中。

其次，请记得为日志相关目录正确配置路径。例如，在共享存储中，实时服务器及其备份必须配置为共享绑定和 消息日志的目录位置 ，以用于大型消息 ，以及进行分页。

JBoss EAP 消息传递定义两种类型的客户端故障转移：

JBoss EAP 消息传递还提供 100% 透明自动重新连接同一服务器（例如，当出现瞬态网络问题时）。这与故障转移类似，除了重新连接到同一服务器并在客户端重新连接和会话附加中讨论。

在故障转移过程中，如果客户端在任何非持久或临时队列上拥有消费者，则在备份节点上故障转移期间将自动重新创建这些队列，因为备份节点将不知道非持久队列。

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:read-resource

/subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:read-resource

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=reconnect-attempts,value=<NEW_VALUE>)

/subsystem=messaging-activemq/server=default/connection-factory=RemoteConnectionFactory:write-attribute(name=initial-connect-attempts,value=<NEW_VALUE>)

本节讨论到实时连接时间(TTL)，并解释 JBoss EAP 消息传递如何处理已退出但未完全关闭资源的崩溃客户端和客户端。

清理服务器上的拒绝连接资源

在 JBoss EAP 客户端应用退出之前，它应当使用 最终 块以受控的方式关闭其资源。

以下是在最终 块中正确关闭其会话和会话工厂的核心客户端的示例 ：

ServerLocator locator = null;
ClientSessionFactory sf = null;
ClientSession session = null;

try {
   locator = ActiveMQClient.createServerLocatorWithoutHA(..);

   sf = locator.createClientSessionFactory();;

   session = sf.createSession(...);

   ... do some stuff with the session...
}
finally {
   if (session != null) {
      session.close();
   }

   if (sf != null) {
      sf.close();
   }

   if(locator != null) {
      locator.close();
   }
}

以下是行为良好的 JMS 客户端应用程序的示例：

Connection jmsConnection = null;

try {
   ConnectionFactory jmsConnectionFactory = ActiveMQJMSClient.createConnectionFactoryWithoutHA(...);

   jmsConnection = jmsConnectionFactory.createConnection();

   ... do some stuff with the connection...
}
finally {
   if (connection != null) {
      connection.close();
   }
}

不幸的是，客户端有时崩溃，无法清理其资源。如果出现这种情况，它可以使服务器端资源挂起在服务器上。如果未移除这些资源，则会导致服务器上的资源泄漏，而且随着时间推移，可能会导致服务器内存或其他资源不足。

在查看清除死的客户端资源时，务必要清楚有时客户端和服务器之间的网络可能会出现故障，然后返回，允许客户端重新连接。由于 JBoss EAP 支持客户端重新连接，因此务必不要太快清理"dead"服务器端资源，否则将阻止任何客户端重新连接并恢复服务器上的旧会话。

JBoss EAP 使所有这些可配置。对于配置的每个 ClientSessionFactory （ Time-To-Live 或 TTL），可以使用 属性来设置服务器在没有客户端的任何数据时保持连接的时长（以毫秒为单位）。客户端将定期自动发送"ping"数据包，以防止服务器关闭其连接。如果服务器在 TTL 时间内没有接收任何数据包，它将自动关闭与该连接相关的服务器中的所有会话。

如果您使用 JMS，连接 TTL 由 ActiveMQConnectionFactory 实例上的 ConnectionTTL 属性定义，或者，如果您部署 JMS 连接工厂实例直接在服务器端的 JNDI 中，您可以使用 connectionTtl 参数在 xml 配置中指定它。

基于网络的连接（如 http-connector） 上的 ConnectionTTL 的默认值为 60000，即 1 分钟。内部连接上的连接 TTL 的默认值（如 in-vm 连接）为 -1。ConnectionTTL 的值为 -1 表示服务器端的连接永远不会超时。

如果您不希望客户端指定自己的连接 TTL，您可以在服务器端设置全局值。这可以通过在服务器配置中指定 connection-ttl-override 属性来完成。connection-ttl-override 的默认值为 -1，表示"不覆盖"，即允许客户端使用自己的值。

关闭核心会话或 JMS 连接

使用完所有核心客户端会话和 JMS 连接时，务必始终在 最后一个块 中明确关闭它们。

如果您未能这样做，JBoss EAP 将在垃圾收集时检测到这一点。然后，它将关闭连接并记录类似如下的警告：

[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  I'm closing a ClientSession you left open. Please make sure you close all ClientSessions explicitly before let
ting them go out of scope!
[Finalizer] 20:14:43,244 WARNING [org.apache.activemq.artemis.core.client.impl.DelegatingSession]  The session you didn't close was created here:
java.lang.Exception
   at org.apache.activemq.artemis.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:83)
   at org.acme.yourproject.YourClass (YourClass.java:666)

请注意，如果您使用 JMS，则警告将涉及 JMS 连接，而不是客户端会话。此外，日志将告知您实例化未关闭的 JMS 连接或核心客户端会话的确切代码行。这样，您可以找出代码中的错误并相应地进行更正。

从客户端幻灯片检测故障

只要客户端从服务器接收数据，它将认为连接处于活动状态。如果客户端没有接收任何 客户端-failure-period 毫秒的任何数据包，它将考虑连接失败，并将启动故障转移，或调用任何 FailureListener 实例，如果您使用 JMS，则发出 ExceptionListener 实例，具体取决于客户端的配置方式。

如果您使用 JMS，则行为由 ActiveMQConnectionFactory 实例上的 ClientFailureCheckPeriod 属性定义。

网络连接中的客户端失败检查周期（如 HTTP 连接）的默认值为 30000 或 30 秒。in-vm 连接中的客户端失败检查期间的默认值为 -1。值 -1 表示客户端端的连接永远不会失败（如果没有从服务器收到任何数据）。无论连接类型如何，检查周期通常都比服务器上连接 TTL 的值小得多，以便客户端能够在发生暂时故障时重新连接。

配置异步连接执行

服务器端收到的大多数数据包都在 远程线程 中执行。这些数据包代表短期运行的操作，出于性能的原因，始终在远程 线程 中执行。

但是，默认情况下，某些类型的数据包是使用来自线程池中的线程来执行的，以便远程 线程 不会太长时间关联。请注意，在另一个线程上异步处理操作会增加延迟。这些数据包是：

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.RollbackMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionCloseMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionCommitMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXACommitMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXAPrepareMessage

org.apache.activemq.artemis.core.protocol.core.impl.wireformat.SessionXARollbackMessage

要禁用异步连接执行，请将 async-connection-execution-enabled 参数设置为 false。默认值为 true。

JBoss EAP 消息传递客户端可以配置为在客户端和服务器之间的连接中检测到故障时自动重新连接或重新连接到服务器。

透明会话附加

如果故障是由于临时网络中断等临时原因造成，并且目标服务器没有重新启动，则该会话仍将存在于该服务器上，假设客户端未断开连接，超过 connection-ttl 的值。请参阅检测检测连接。

在这种情况下，在进行重新连接时，JBoss EAP 将自动将客户端会话重新关联到服务器会话。100% 透明地完成此操作，客户可以完全像没有发生任何情况一样继续操作。

当 JBoss EAP 消息传递客户端向服务器发送命令时，它们将各个发送的命令存储在内存中缓冲区中。当连接失败并且客户端随后尝试重新连接到同一服务器时，作为重新附加协议的一部分，服务器会为客户端提供其成功收到的最后一个命令的 id。

如果客户端发送的命令超过故障转移前收到的命令，它可以重播其缓冲区中发送的任何命令，以便客户端和服务器可以协调其状态。

此缓冲区的大小由firm WindowSize 属性设置。当服务器收到 Confirm WindowSize bytes 字节并处理后，它会向客户端发回一个命令确认，客户端随后可以在缓冲区中释放空间。

如果您使用服务器上的 JMS 服务将 JMS 连接工厂实例加载到 JNDI 中，可以通过设置所选 connection-factory 的firm -window-size 属性在服务器配置中配置此属性。如果您使用 JMS 但不使用 JNDI，则您可以使用适当的 setter 方法直接在 ActiveMQConnectionFactory 实例上设置这些值，setConfirmationWindowSize。如果您使用核心 API，Server Locator 实例也公开了 setConfirmationWindowSize 方法。

将 confirmWindowSize 设置为 -1 （也是默认设置）会禁用任何缓冲，并防止发生任何重新附加，从而迫使重新连接。

会话重新连接

或者，服务器可能已在崩溃后实际重新启动，或者可能已被停止。在这种情况下，服务器上不再存在任何会话，且无法透明地重新连接它们。

在这种情况下，JBoss EAP 将自动重新连接连接，并在服务器上重新创建与客户端上的会话和使用者对应的任何会话和使用者。此过程与故障转移到备份服务器时所发生的情况完全相同。

客户端重新连接也由核心网桥等组件在内部使用，以允许它们重新连接到其目标服务器。

请参阅自动客户端故障部分，以深入了解如何在重新连接期间重新连接转换和非转换会话，以及维护一次且仅一次交付保证所需的操作。

配置重新连接属性

通过设置以下属性来配置客户端重新连接：

如果您在客户端上使用 JMS 和 JNDI 来查找您的 JMS 连接工厂实例，则可以在 JNDI 上下文环境中指定这些参数。例如，您的 jndi.properties 文件可能类似如下：

java.naming.factory.initial = ActiveMQInitialContextFactory
connection.ConnectionFactory=tcp://localhost:8080?retryInterval=1000&retryIntervalMultiplier=1.5&maxRetryInterval=60000&reconnectAttempts=1000

如果您使用 JMS，但直接实例化 JMS 连接工厂，您可以在创建后立即在 ActiveMQConnectionFactory 上使用适当的 setter 方法指定参数。

如果您使用核心 API 并直接实例化 ServerLocator 实例，您也可以在创建后立即使用 ServerLocator 上的适当 setter 方法指定参数。

如果您的客户端能够成功重新连接，但会话在服务器上不再可用，例如，如果服务器重新启动或超时，客户端将无法重新连接，并且将调用连接或会话中注册的任何 Exception Listener 或 FailureListener 实例。

ExceptionListeners 和 SessionFailureListeners

请注意，当客户端重新连接或重新连接时，将调用任何注册的 JMS ExceptionListener 或 core API SessionFailureListener。

JBoss EAP 7 包括一个集成的 Artemis 资源适配器，它使用 pooled-connection-factory 元素来配置资源适配器的出站和入站连接。

出站连接

出站连接使用 pooled-connection-factory 元素来定义，然后由 Jakarta Enterprise Beans 和 servlets 在 Jakarta EE 部署中使用该元素将消息发送到队列或主题并接收消息。因为从连接工厂创建的连接是在应用服务器范围内创建的，所以它们可以使用类似如下的应用服务器功能：

这是 pooled-connection-factory 的主要区别，因为这些功能不适用于 InVmConnectionFactory 或 RemoteConnectionFactory 等基本连接 事实。另外，请注意，通过使用 pooled-connection-factory 定义的连接工厂，无法从外部单机 JMS 客户端使用 JNDI 进行查找。

入站连接

入站连接仅由消息驱动型 Bean(MDB)用于从队列或主题接收消息。MDB 是侦听队列或主题的无状态会话 Bean。它们必须实施公共 onMessage（消息） 方法，该方法在消息发送到队列或主题时调用。Artemis 资源适配器负责从队列或主题接收消息，并将它传递到 onMessage（Message 消息） 方法。为此，它会配置入站连接，定义集成 Artemis 服务器的位置和其他一些元素。

每个 MDB 会话 bean 使用来自客户端线程池的线程来消耗来自目的地的消息。如果未定义最大池大小，则将其确定为 CPU 内核处理器的八(8)倍。对于有许多 MDB 会话的系统，如测试套件，这可能会导致线程耗尽，并强制 MDB 从池中等待一个空闲的线程。您可以使用管理 CLI 增加客户端线程池的最大池大小。以下命令将最大客户端线程池大小设置为 128。

/subsystem=messaging-activemq:write-attribute(name=global-client-thread-pool-max-size,value=128)

有关如何配置客户端线程池大小的详情，请参考客户端线程管理。如需有关 MDB 的更多信息，请参阅 JBoss EAP 开发 EJB 应用 https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.3/html-single/developing_ejb_applications/#message_driven_beans-1 的消息驱动 Bean。

JBoss EAP 包括一个资源适配器，可用于连接其集成的 ActiveMQ Artemis 消息服务器。默认情况下，messaging- activemq 子系统中定义的 pooled- connection-factory 使用适配器来进行连接。但是，您也可以使用相同的资源适配器来连接在 JBoss EAP 远程实例中运行的 Artemis 服务器。

WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.DefaultJMSConnectionFactory"]

若要连接在 JBoss EAP 远程实例中运行的 Artemis 服务器，请 按照以下步骤创建新的 pooled-connection-factory ：

将 MDB 配置为使用 pooled-connection-factory

在将 pooled-connection-factory 配置为连接到远程 Artemis 服务器后，必须先使用 pooled-connection-factory 资源的名称为来自远程服务器的 Message-Driven Beans (MDB)注释掉 @ResourceAdapter 注释。

import org.jboss.ejb3.annotation.ResourceAdapter;

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = { ... })
public class MyMDB implements MessageListener {
    public void onMessage(Message message) {
       ...
    }
}

如果 MDB 需要发送消息到远程服务器，则必须使用其中一个 JNDI 条目 查找 pooled-connection-factory 来注入 pooled-connection-factory。

@Inject
@JMSConnectionFactory("java:/jms/remoteCF")
private JMSContext context;

配置 JMS 目的地

MDB 还必须指定它将使用消息的目的地。执行此操作的标准方法是定义与本地服务器上的 JNDI 查找对应的 destinationLookup 激活配置属性。

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = {
    @ActivationConfigProperty(propertyName = "destinationLookup", propertyValue = "myQueue"),
    ...
})
public class MyMDB implements MessageListener {
    ...
}

如果本地服务器不为远程 Artemis 服务器包含 JNDI 绑定，请指定目的地名称，如远程 Artemis 服务器中配置，使用 目标 激活配置属性，并将 useJNDI 激活配置属性设置为 false。这指示 Artemis 资源适配器自动创建 JMS 目的地，而无需 JNDI 查找。

@ResourceAdapter("remote-artemis")
@MessageDriven(name = "MyMDB", activationConfig = {
    @ActivationConfigProperty(propertyName = "useJNDI", propertyValue = "false"),
    @ActivationConfigProperty(propertyName = "destination", propertyValue = "myQueue"),
    ...
})
public class MyMDB implements MessageListener {
    ...
}

在上例中，激活配置属性将 MDB 配置为使用来自远程 Artemis 服务器上托管的名为 myQueue 的 JMS Queue 的消息。在大多数情况下，MDB 不需要查找其他目的地来处理已使用的消息，如果消息上定义了 JMSReplyTo 目标，它也可使用它。

如果 MDB 需要远程服务器上定义的任何其他 JMS 目的地，则必须使用客户端 JNDI。如需更多信息，请参阅 连接到服务器。

您可以配置集成的 Artemis 资源适配器，以连接到 Red Hat AMQ 7 的远程安装，然后成为 JBoss EAP 7.3 应用的 JMS 供应商。这使得 JBoss EAP 能够成为远程红帽 AMQ 7 服务器的客户端。

如果需要支持其他消息传递协议，如 AMQP 或 STOMP，您必须将 Red Hat AMQ 7 配置为您的消息传递代理。然后，JBoss EAP 服务器中集成的 Artemis 资源适配器可用于处理已部署应用的消息。

集成资源适配器的限制

队列和主题的动态创建

请注意，集成在 JBoss EAP 7.3 中的 Artemis 资源适配器不支持在红帽 AMQ 7 代理中动态创建队列和主题。您必须直接在远程 Red Hat AMQ 7 服务器上配置所有队列和主题目的地。

创建连接事实

尽管红帽 AMQ 允许同时使用 pooled-connection-factory 和 external- context 配置连接工厂，但每个连接工厂的创建方式会有差别。使用 external-context 创建连接工厂时，它会创建 JMS 规范中定义的简单 JMS 连接工厂。新创建的连接工厂等同于 RemoteConnectionFactory，它在 messaging-activemq 子系统中默认定义。此连接工厂独立于应用服务器中的其他组件，这意味着它不知道并且无法使用其他组件，如交易管理器或安全管理器。因此，只有 pooled-connection-factory 可用于在 JBoss EAP 7 中创建连接工厂。external-context 只能用于将已在远程 AMQ 7 代理上的 JMS 目的地注册到 JBoss EAP 7 服务器的 JNDI 树中，以便本地部署可以查找或注入它们。

通过配置 external-context 或 connection- factory 元素所创建的连接工厂无法用于连接到远程 AMQ 7 代理，因为它们不使用 Artemis 资源适配器。在连接远程 AMQ7 代理时，仅支持配置 pooled-connection-factory 元素所创建的连接工厂。

配置 JBoss EAP 以使用远程红帽 AMQ 服务器

您可以按照以下步骤使用管理 CLI 将 JBoss EAP 配置为使用 Red Hat AMQ 7 的远程安装作为消息传递提供程序：

JBoss EAP 现已配置为使用红帽 AMQ 7 的远程安装作为消息传递提供商。

在管理 CLI 中，您可以使用 @JMS ConnectionFactoryDefinition 注释或 @JMSDestinationDefinition 注释，为基于 Artemis 的远程代理（如红帽 AMQ 7）配置 JMS 资源。您也可以从管理控制台配置资源。

远程 ActiveMQ 服务器资源不需要本地实例 Artemis。这有助于减少 JBoss EAP 映像的内存占用和 CPU 占用。

您可以部署红帽 JBoss A-MQ 产品提供的资源适配器，例如红帽 JBoss A-MQ 6.3.0，已成为 JBoss EAP 的外部 JMS 提供商。

有关如何部署和配置红帽 JBoss A-MQ 资源适配器的详细信息，请参阅红帽 JBoss A-MQ 文档套件中的 JBoss 企业应用平台安装 ActiveMQ 资源适配器。

关于 IBM MQ

IBM MQ 是来自 IBM 的消息传递导向型中间件(MOM)产品，允许分布式系统上的应用程序相互通信。这通过使用消息和消息队列来完成。IBM MQ 负责发送消息到消息队列，以及使用消息通道将数据传输到其他队列管理器。有关 IBM MQ 的更多信息，请参阅 IBM 产品网站上的 IBM MQ。

概述

IBM MQ 可以配置为 JBoss EAP 7.3 的外部 JMS 提供程序。本节介绍在 JBoss EAP 中部署和配置 IBM MQ 资源适配器的步骤。此部署和配置可使用管理 CLI 工具或基于 Web 的管理控制台来完成。有关 IBM MQ 支持配置的最新信息，请参阅 JBoss EAP 支持的配置。

先决条件

开始之前，您必须验证 IBM MQ 资源适配器的版本并了解其配置属性。

流程

@ActivationConfigProperty(propertyName = "destination", propertyValue = "QUEUE")

@JMSConnectionFactoryDefinition(
    name = "java:/jms/WMQConnectionFactory",
    interfaceName = "javax.jms.ConnectionFactory",
    resourceAdapter = "wmq.jmsra",
    properties = {
        "channel=<channel>",
        "hostName=<hostname_wmq_broker>",
        "transportType=<transport_type>",
        "queueManager=<queue_manager>"
    }
)

@Inject
@JMSConnectionFactory("jms/CF")
@JMSPasswordCredential(userName="myusername", password="mypassword")
@JMSSessionMode(JMSContext.DUPS_OK_ACKNOWLEDGE)
transient JMSContext context3;

WARN  [org.jboss.jca.core.connectionmanager.pool.strategy.PoolByCri] (EJB default - 7) IJ000604: Throwable while attempting to get a new connection: null: com.ibm.mq.connector.DetailedResourceException: MQJCA1011: Failed to allocate a JMS connection., error code: MQJCA1011 An internal error caused an attempt to allocate a connection to fail. See the linked exception for details of the failure.

QueueConnection qc = queueConnectionFactory.createQueueConnection("invalidUserName", "invalidPassword");

SVR-ERROR: Expected JMSException, received com.ibm.mq.connector.outbound.MQQueueProxy cannot be cast to com.ibm.mq.jms.MQDestination

ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /jmsServlet-1.0-SNAPSHOT/: com.ibm.msg.client.jms.DetailedJMSRuntimeException: MQJCA0002: An exception occurred in the IBM MQ layer. See the linked exception for details.
A call to IBM MQ classes for Java(tm) caused an exception to be thrown.

SVR-ERROR: com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ2007: Failed to send a message to destination 'MDB_NAME TOPIC_NAME'

com.ibm.mq.MQException: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED') reason '2072' ('MQRC_SYNCPOINT_NOT_AVAILABLE')

WARN  [org.jboss.as.connector.deployers.RADeployer] (MSC service thread 1-8) IJ020017: Invalid archive: file:/<path-to-jboss>/jboss-eap-7.3/standalone/tmp/vfs/temp/tempa02bdd5ee254e590/content-135e13d4f38704fc/contents/

/subsystem=jca/archive-validation=archive-validation:write-attribute(name=enabled, value=false)

JBoss EAP 可以配置为与第三方 Jakarta 消息传递提供商合作；然而，并非所有 Jakarta 消息传递提供商都生产用于与 Jakarta 应用平台集成的 Jakarta 消息传递器资源适配器。此流程涵盖配置 JBoss EAP 中包含的通用 Jakarta 消息传递资源适配器以连接 Jakarta 消息传递提供商所需的步骤。在此流程中，Tibco EMS 8 用作 Jakarta 消息传递供应商的示例。其他 Jakarta 消息传递提供商可能需要不同的配置。

在配置通用资源适配器前，您需要执行以下操作：

在此流程中使用的 XML 示例中，这些参数分别写为 PROVIDER_FACTORY_INITIAL、PROVIDER_URL 和 PROVIDER_CONNECTION_FACTORY。将这些占位符替换为您的环境的 Jakarta 消息传递供应商值。

@MessageDriven(name = "HelloWorldQueueMDB", activationConfig = {
  // The generic Jakarta Messaging resource adapter requires the  Java Naming and Directory Interface bindings
  // for the actual remote connection factory and destination
  @ActivationConfigProperty(propertyName = "connectionFactory", propertyValue = "java:global/remoteJMS/XAQCF"),
  @ActivationConfigProperty(propertyName = "destination", propertyValue = "java:global/remoteJMS/Queue1"),
  @ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue"),
  @ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge") })
  public class HelloWorldQueueMDB implements MessageListener {
  public void onMessage(Message message) {
  // called every time a message is received from the _Queue1_ queue on the Jakarta Messaging provider.
  }
}

@Resource(lookup = "java:/jms/XAQCF")
private ConnectionFactory cf;

@Resource(lookup = "java:global/remoteJMS")
private Context context;
...
Queue queue = (Queue) context.lookup("Queue1")

利用 @Resource 注释，Jakarta Enterprise Beans 可以直接注入 Jakarta 消息资源或连接工厂。您可以使用 @Resource 注释指定以下参数：

若要注入资源，您必须在其中一个参数中指定资源的 Java 命名和目录接口(JNDI)名称。

向前兼容性不需要更改旧版 JBoss EAP 6 JMS 客户端的代码。JBoss EAP messaging-activemq 子系统及其资源提供支持。为了支持向前兼容性，需要对 JBoss EAP 7 服务器的配置进行以下更改：每个步骤都提供了单机服务器的管理 CLI 命令示例：

管理 CLI 迁移操作

当您运行管理 CLI 迁移 操作以更新 消息传递 子系统配置时，如果布尔值参数 add-legacy-entries 设为 true，delay -activemq 子系统会创建 legacy-connection-factory 资源，并将 legacy-entries 添加到 jms-queue 和 jms-topic 资源。迁移的 messaging-activemq 子系统中的传统条目将与传统 消息传递 子系统中指定的条目对应，而常规条目则使用 -new 后缀创建。

如果在运行 迁移 操作时将布尔值参数 add-legacy-entries 设置为 false，则 messaging-activemq 子系统中不会创建传统资源，并且传统的 JMS 客户端将无法与 JBoss EAP 7 服务器通信。

向后兼容性不需要更改旧版 JBoss EAP 7 服务器中的配置更改。JBoss EAP 7 JMS 客户端不查找传统服务器上的资源，而是使用客户端 JNDI 来创建 JMS 资源。JBoss EAP 7 JMS 客户端随后可以利用这些资源使用 HornetQ 核心协议与传统服务器通信。

JBoss EAP 消息传递支持客户端 JNDI 创建 JMS ConnectionFactory 和 Destination 资源。

例如，如果 JBoss EAP 7 JMS 客户端希望使用名为"myQueue"的 JMS 队列与传统服务器通信，则必须使用以下属性来配置其 JNDI InitialContext ：

java.naming.factory.initial=org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory
connectionFactory.jms/ConnectionFactory=tcp://<legacy server address>:5445? \
    protocolManagerFactoryStr=org.apache.activemq.artemis.core.protocol.hornetq.client.HornetQClientProtocolManagerFactory
queue.jms/myQueue=myQueue

然后，客户端可以使用 jms/ConnectionFactory 名称来创建 JMS ConnectionFactory，并使用 jms/myQueue 创建 JMS Queue。请注意，在指定传统连接工厂的 URL 时，属性 protocolManagerFactoryStr=org.apache.activemq.artemis.core.protocolq.client.HornetQClientProtocolManagerFactory 是必需的。这使得 JBoss EAP 消息传递 JMS 客户端能够与传统服务器中的 HornetQ 代理通信。

由于这可能会对性能造成负面影响，因此默认情况下 不会 启用 messaging-activemq 子系统的统计数据收集。您不需要启用队列统计信息来获取基本信息，如队列中的消息数或添加到队列的消息数量。这些统计数据可使用队列属性提供，而无需将 启用了统计信息 设置为 true。

您可以使用管理 CLI 或管理控制台启用其他统计信息收集。

使用管理 CLI 启用消息传递统计信息

以下管理 CLI 命令启用 默认 消息传递服务器的统计信息集合：

/subsystem=messaging-activemq/server=default:write-attribute(name=statistics-enabled,value=true)

池连接工厂统计数据是独立于其他消息传递服务器统计数据启用的。使用以下命令，启用池连接工厂的统计数据。

/subsystem=messaging-activemq/server=default/pooled-connection-factory=activemq-ra:write-attribute(name=statistics-enabled,value=true)

重新加载服务器以使更改生效。

使用管理控制台启用消息传递统计信息

使用以下步骤，通过管理控制台为消息传递服务器启用统计信息集合。

池连接工厂统计数据是独立于其他消息传递服务器统计数据启用的。使用以下步骤为池式连接工厂启用统计信息集合。

您可以使用管理 CLI 或管理控制台查看消息传递服务器的运行时统计信息。

使用管理 CLI 查看消息传递统计信息

您可以使用以下管理 CLI 命令查看消息传递统计信息：务必包含 include-runtime=true 参数，因为统计信息是运行时信息。

使用管理控制台查看消息传递统计信息

若要从管理控制台查看消息传递统计信息，可从 Runtime 选项卡导航到 Messaging(ActiveMQ) 子系统，再选择服务器。选择目标以查看其统计信息。

如需了解所有可用统计数据的详细列表，请参阅消息传递统计信息。

您可以为消息传递服务器配置以下消息计数器属性：

管理 CLI 命令使用这些语法来配置这些选项：务必将 STATISTICS_NAME 和 STATISTICS_VALUE 替换为您要配置的统计名称和值。

/subsystem=messaging-activemq/server=default::write-attribute(name=STATISTICS_NAME,value=STATISTICS_VALUE)

例如，使用以下命令将 message-counter-max-day-history 设为 5 天，message-counter-sample-period 设为 2 秒。

/subsystem=messaging-activemq/server=default:write-attribute(name=message-counter-max-day-history,value=5)
/subsystem=messaging-activemq/server=default:write-attribute(name=message-counter-sample-period,value=2000)

您可以使用以下管理 CLI 操作查看队列的消息计数器和消息计数器历史记录。

用于显示这些值的管理 CLI 命令使用以下语法：务必将 QUEUE_NAME 和 OPERATION_NAME 替换为您要使用的队列名称和操作。

/subsystem=messaging-activemq/server=default/jms-queue=QUEUE_NAME:OPERATION_NAME

例如，使用以下命令，以 JSON 格式查看 TestQueue 队列的消息计数器：

/subsystem=messaging-activemq/server=default/jms-queue=TestQueue:list-message-counter-as-json
{
    "outcome" => "success",
    "result" => "{\"destinationName\":\"TestQueue\",\"destinationSubscription\":null,\"destinationDurable\":true,\"count\":0,\"countDelta\":0,\"messageCount\":0,\"messageCountDelta\":0,\"lastAddTimestamp\":\"12/31/69 7:00:00 PM\",\"updateTimestamp\":\"2/20/18 2:24:05 PM\"}"
}

您可以使用 reset-message-counter 管理 CLI 操作重置队列的消息计数器。

/subsystem=messaging-activemq/server=default/jms-queue=TestQueue:reset-message-counter
{
    "outcome" => "success",
    "result" => undefined
}

使用管理控制台，您可以：

执行强制故障到其他消息传递服务器

为消息传递服务器重置所有消息计数器

为消息传递服务器重置消息计数器历史

查看与消息传递服务器相关的信息

使用管理控制台，您可以查看与消息传递服务器相关的以下信息列表：

查看与消息传递服务器相关的信息：

关闭消息传递服务器的连接

您可以通过提供 IP 地址、ActiveMQ 地址匹配或用户名来关闭连接。

关闭消息传递服务器的连接：

为消息传递服务器滚动后端事务

为消息传递服务器提交事务