如何捕获 ActiveMQAddressFullException？答案

【问题标题】：How to catch ActiveMQAddressFullException?如何捕获 ActiveMQAddressFullException？
【发布时间】：2021-06-15 04:36:31
【问题描述】：

使用 WildFly 和嵌入式 ActiveMQ Artemis 作为 JMS 实现。队列设置有固定的内存大小，如果队列已满，则FAIL 操作。我需要能够捕获产生的异常，以便客户端停止发送新消息。但是，调用send的时候好像没有出现异常，而是在事务的最后几个方法上来了。我不确定如何正确处理。

【问题讨论】：

标签： jms wildfly activemq-artemis

【解决方案1】：

如果您正在使用事务，那么当您在 JMS MessageProducer 上调用 send 时，消息实际上不会发送。它们的消息仅在事务提交时发送。像这样将多个操作批处理在一起是事务的主要特征之一。如果在提交事务时发送消息有问题，则事务提交将失败，但“发送”消息的特定MessageProducer 将不知道它。您需要停止使用交易或以另一种方式通知发件人问题（这只会追溯）。

如果您仅使用事务，因为您需要知道消息已成功到达队列并且您不需要将多个 JMS 操作组合到一个逻辑单元中，那么您可以停止使用事务，并且：

确保您发送的是持久（即持久）消息。
在您的客户端 URL 中设置 blockOnNonDurableSend=true 是您发送非持久（即非持久）消息。

在任何一种情况下，客户端都将等待来自代理的响应，即消息已成功接收。您可以在the ActiveMQ Artemis documentation 中阅读更多相关信息。

如果您的客户端等待响应超时，那么这可能意味着代理没有收到消息，您可以再次发送它。但是，在某些情况下，代理（或网络）可能会失败消息被成功接收但之前响应可以到达客户端。在这些情况下，如果客户端再次发送消息，可能会导致重复。为了降低重复的风险，您可以在消息上设置重复 ID 并在代理上使用重复检测。你可以在the ActiveMQ Artemis documentation阅读更多关于重复检测的内容。

在任何情况下，无论是在调用 send 时实际发送消息，还是稍后在调用 commit 时发送消息，如果自从您到达 max-size-bytes '正在使用FAIL。

【讨论】：

谢谢。我们确实需要继续使用事务，因为我们需要知道消息是否已排队。鉴于此，您对我们如何实施某种流量控制有什么建议吗？我们遇到的问题是，当系统负载过重时，所有消息都被分页到磁盘，最终会填满整个磁盘。如果队列已经“满”，我们需要找到一种以编程方式不对更多请求进行排队的方法。不幸的是，标准 JMS API 似乎根本不支持这种用例。
我更新了我的答案以解决您的评论。希望有帮助！
谢谢。仍然需要消化这一点，看看如何在 WildFly 上下文和我们的应用程序中应用它。无论如何都会标记为正确。