此内容没有您所选择的语言版本。

Chapter 19. Message Redelivery and Undelivered Messages


Message delivery can be unsuccessful, for example, if the session used to consume a message is rolled back. An undelivered message returns to the queue ready to be redelivered. However, this means multiple unsuccessful deliveries are possible, so messages can remain in the queue, clogging the system.
There are two options for these undelivered messages:
Delayed Redelivery
Message delivery can be delayed to allow the client time to recover from transient failures and not overload its network or CPU resources.
Dead Letter Address
Configure a dead letter address, to which messages are sent after being determined undeliverable.
These options can be combined for maximum flexibility.

19.1. Delayed Redelivery

Delaying redelivery can be useful for clients that regularly fail or roll back. Without delayed redelivery, the system can get into a "thrashing" state, where delivery fails and the client rolls back to attempt redelivery ad infinitum, consuming CPU and network resources.

19.1.1. Configuring Delayed Redelivery

Delayed redelivery is defined in the address-setting configuration:
<!-- delay redelivery of messages for 5s -->
<address-setting match="jms.queue.exampleQueue">
   <redelivery-delay>5000</redelivery-delay>
</address-setting>
Copy to Clipboard Toggle word wrap
If a redelivery-delay is specified, HornetQ will wait that many milliseconds before redelivering the messages. Redelivery delay is enabled by default and set to 60000 (1 minute).
Address wildcards can be used to configure redelivery delay for a set of addresses (see Chapter 11, Understanding the HornetQ Wildcard Syntax), so redelivery delay does not have to be specified for each address individually.
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat