Jms 如何捕获ActiveMQAddressFullException？

使用带有嵌入式ActiveMQ Artemis的WildFly作为JMS实现。使用固定内存大小设置队列，如果队列已满，则执行

FAIL

操作。我需要能够捕获结果异常，以便客户端停止发送新消息。但是，调用send时似乎不会发生异常，但在事务结束时，会启动一些方法。我不确定如何正确处理此问题。

如果您使用的是事务，那么在JMS

MessageProducer

上调用

send

时，消息实际上不会发送。它们仅在事务提交时发送消息。像这样将多个操作批处理在一起是事务的主要特性之一。如果在提交事务时发送消息时出现问题，则事务提交将失败，但“发送”消息的特定

MessageProducer

将不知道该问题。您需要停止使用事务或以另一种方式通知发件人问题（该方式仅具有追溯效力）

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

确保您正在发送持久（即持久）消息

在客户端URL中设置

blockOnNonDurableSend=true

表示您正在发送非持久性（即非持久性）消息

在任何一种情况下，客户机都将等待代理成功接收消息的响应。您可以在中阅读更多关于此的信息

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

---

在任何情况下，无论是在调用

send

时实际发送消息，还是在稍后调用

commit

时实际发送消息，如果在使用

FAIL

后已达到

max size bytes

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