Message Listener Container Configuration

有很多选择用于配置与事务和服务质量相关的 SimpleMessageListenerContainer （SMLC）和 DirectMessageListenerContainer （DMLC），并且一些选择会相互作用。应用于 SMLC、DMLC 或 StreamListenerContainer （StLC）的属性（请参见 Using the RabbitMQ Stream Plugin）由相应列中的复选标记表示。请参见 Choosing a Container，以获取帮助您确定哪个容器适合您的应用程序的信息。

下表显示了容器属性名称及其等效属性名称（括号内），其中使用命名空间配置 <rabbit:listener-container/> 时。该元素上的 type 属性可以是 simple（默认）或 direct，分别指定 SMLC 或 DMLC。命名空间不公开某些属性。这些属性由属性的 N/A 表示。

Table 1. Configuration options for a message listener container
Property (Attribute)	Description	SMLC	DMLC	StLC
[id="ackTimeout"]<<`ackTimeout`,ackTimeout>> (N/A)	当 `messagesPerAck` 被设置时，该超时用作发送 ack 的备选方案。当一条新消息到达时，将未 ack 消息的数量与 `messagesPerAck` 进行比较，并且将上次 ack 后的时间与此值进行比较。如果任一条件为 `true`，则消息将被确认。当没有新消息到达且有未 ack 消息时，此超时是个近似值，因为条件仅在每个 `monitorInterval` 检查一次。请参阅此表格中的 `messagesPerAck` 和 `monitorInterval`。		image::tickmark.png[]
[id="acknowledgeMode"]<<`acknowledgeMode`,acknowledgeMode>> (acknowledge)	* `NONE`：不发送 ack（与 `channelTransacted=true` 不兼容）。RabbitMQ 称其为 “autoack”，因为代理假设所有消息都已 ack，而无需消费者采取任何操作。* `MANUAL`：监听器必须通过调用 `Channel.basicAck()` 确认所有消息。* `AUTO`：容器自动确认消息，除非 `MessageListener` 抛出异常。请注意，`acknowledgeMode` 与 `channelTransacted` 互补——如果通道进行事务处理，则代理除了 ack 之外还需要确认通知。这是默认模式。请参阅 `batchSize`。	image::tickmark.png[]	image::tickmark.png[]
[id="adviceChain"]<<`adviceChain`,adviceChain>> (advice-chain)	要应用到监听器执行的 AOP 建议的数组。可用于应用其他横切关注点，例如在代理死亡时自动重试。请注意，AMQP 错误后的简单重新连接由 `CachingConnectionFactory` 处理，只要代理仍然存活。	image::tickmark.png[]	image::tickmark.png[]
[id="afterReceivePostProcessors"]<<`afterReceivePostProcessors`,afterReceivePostProcessors>> (N/A)	在调用监听器之前调用的 `MessagePostProcessor` 实例的数组。后置处理器可以实现 `PriorityOrdered` 或 `Ordered`。该数组是按排好序的，最后调用无序的成员。如果后置处理器返回 `null`，则丢弃消息（并适当地确认）。	image::tickmark.png[]	image::tickmark.png[]
[id="alwaysRequeueWithTxManagerRollback"]<<`alwaysRequeueWithTxManagerRollback`,alwaysRequeueWithTxManagerRollback>> (N/A)	如果配置了事务管理器，则在回滚时设置为 `true`，以便始终重新排队消息。	image::tickmark.png[]	image::tickmark.png[]
[id="autoDeclare"]<<`autoDeclare`,autoDeclare>> (auto-declare)	当设为 `true`（默认）时，如果容器在启动期间检测到至少一个队列丢失，则容器将使用 `RabbitAdmin` 重新声明所有 AMQP 对象（队列、交换、绑定），或许是因为它是一个 `auto-delete` 或过期的队列，但是无论出于任何原因导致队列丢失，都将继续重新声明。要禁用此行为，请将此属性设为 `false`。请注意，如果容器的所有队列都丢失，则容器无法启动。[NOTE]======在 1.6 版之前，如果上下文中有多个管理员，则容器将随机选择一个。如果没有管理员，它会在内部创建一个。在这两种情况下，这都可能导致意外的结果。从 1.6 版开始，要使 `autoDeclare` 正常工作，上下文中必须有且仅有一个 `RabbitAdmin`，或者必须使用 `rabbitAdmin` 属性在容器上配置对特定实例的引用。======	image::tickmark.png[]	image::tickmark.png[]
[id="autoStartup"]<<`autoStartup`,autoStartup>> (auto-startup)	指示容器应在 `ApplicationContext` 启动（作为 `SmartLifecycle` 回调的一部分，在所有 bean 初始化后发生）时的标志。默认为 `true`，但如果您的代理在启动时可能不可用，您可以将其设置为 `false`，稍后在您知道代理已就绪时手动调用 `start()`。	image::tickmark.png[]	image::tickmark.png[]	image::tickmark.png[]
[id="batchSize"]<<`batchSize`,batchSize>> (transaction-size) (batch-size)	当与设置为 `AUTO` 的 `acknowledgeMode` 一起使用时，容器在发送 ack（等待每个收到超时设置）之前尝试处理多达此数量的消息。这也是提交事务通道的时间。如果 `prefetchCount` 小于 `batchSize`，则将其增加以匹配 `batchSize`。	image::tickmark.png[]
[id="batchingStrategy"]<<`batchingStrategy`,batchingStrategy>> (N/A)	对消息进行解除批处理时使用的策略。默认值 `SimpleDebatchingStrategy`。请参阅 Batching 和 @RabbitListener with Batching。	image::tickmark.png[]	image::tickmark.png[]
[id="channelTransacted"]<<`channelTransacted`,channelTransacted>> (channel-transacted)	布尔标志，表示应在事务中确认所有消息（手动或自动）。	image::tickmark.png[]	image::tickmark.png[]
[id="concurrency"]<<`concurrency`,concurrency>> (N/A)	`m-n` 每个侦听器的并行使用者范围（最小值、最大值）。如果仅提供 `n`，则 `n` 是固定数量的使用者。请参阅 Listener Concurrency。	image::tickmark.png[]
[id="concurrentConsumers"]<<`concurrentConsumers`,concurrentConsumers>> (concurrency)	为每个侦听器最初启动的并行使用者数量。请参阅 Listener Concurrency。对于 `StLC`，通过重载的 `superStream` 方法控制并发性；请参阅 Consuming Super Streams with Single Active Consumers。	image::tickmark.png[]		image::tickmark.png[]
[id="connectionFactory"]<<`connectionFactory`,connectionFactory>> (connection-factory)	对 `ConnectionFactory` 的引用。通过使用 XML 命名空间进行配置时，默认引用的 Bean 名称是 `rabbitConnectionFactory`。	image::tickmark.png[]	image::tickmark.png[]
[id="consecutiveActiveTrigger"]<<`consecutiveActiveTrigger`,consecutiveActiveTrigger>> (min-consecutive-active)	在考虑启动新的使用者时，使用者收到的连续消息的最小数量（不发生接受超时）。也受“batchSize”影响。请参阅 Listener Concurrency。默认值：10。	image::tickmark.png[]
[id="consecutiveIdleTrigger"]<<`consecutiveIdleTrigger`,consecutiveIdleTrigger>> (min-consecutive-idle)	使用者必须经历的最小接受超时次数，然后考虑停止使用者。也受“batchSize”影响。请参阅 Listener Concurrency。默认值：10。	image::tickmark.png[]
[id="consumerBatchEnabled"]<<`consumerBatchEnabled`,consumerBatchEnabled>> (batch-enabled)	如果 `MessageListener` 支持，将此设置为 true 将启用离散消息的批处理（最多 `batchSize`）；如果 `receiveTimeout` 内未收到新消息或收集批处理消息时间超过 `batchReceiveTimeout`，则将传递部分批处理。当此为 false 时，仅支持由生产者创建的批处理；请参阅 Batching。	image::tickmark.png[]
[id="consumerCustomizer"]<<`consumerCustomizer`,consumerCustomizer>> (N/A)	由容器创建的流消费者的 `ConsumerCustomizer` Bean 用于修改。			image::tickmark.png[]
[id="consumerStartTimeout"]<<`consumerStartTimeout`,consumerStartTimeout>> (N/A)	让使用者线程启动的等待时间，单位为毫秒。如果超过此时间，将写一条错误日志。此问题可能会发生的一个示例是，如果配置的 `taskExecutor` 的线程不足以支持容器 `concurrentConsumers`。请参阅 Threading and Asynchronous Consumers。默认值：60000（一分钟）。	image::tickmark.png[]
[id="consumerTagStrategy"]<<`consumerTagStrategy`,consumerTagStrategy>> (consumer-tag-strategy)	设置 ConsumerTagStrategy 的实现，启用为每个使用者创建（唯一）标签。	image::tickmark.png[]	image::tickmark.png[]
[id="consumersPerQueue"]<<`consumersPerQueue`,consumersPerQueue>> (consumers-per-queue)	为每个配置队列创建的使用者数量。请参阅 Listener Concurrency。		image::tickmark.png[]
[id="consumeDelay"]<<`consumeDelay`,consumeDelay>> (N/A)	在 `concurrentConsumers > 1` 中使用 RabbitMQ Sharding Plugin 时，存在竞争条件，可能会阻止使用者在分片之间均匀分布。使用此属性可在使用者启动之间添加较小延迟，以避免此竞争条件。您应该尝试使用不同的值来确定适合您环境的延迟时间。	image::tickmark.png[]	image::tickmark.png[]
[id="debatchingEnabled"]<<`debatchingEnabled`,debatchingEnabled>> (N/A)	为 true 时，侦听器容器将对批处理消息进行解除批处理，并使用批处理中的每条消息调用侦听器。从 2.2.7 版开始，如果侦听器是 `BatchMessageListener` 或 `ChannelAwareBatchMessageListener`，则 producer created batches 将被解除批处理为 `List<Message>`。否则，将分别显示批处理中的消息。默认值为真。请参阅 Batching 和 @RabbitListener with Batching。	image::tickmark.png[]	image::tickmark.png[]
[id="declarationRetries"]<<`declarationRetries`,declarationRetries>> (declaration-retries)	被动队列声明失败时的重试次数。被动队列声明在使用者启动时发生，或者在从多个队列使用时，在初始化期间并非所有队列都可用时发生。当在重试耗尽后无法被动声明（由于任何原因）任何已配置的队列时，容器行为由前面描述的“missingQueuesFatal`属性控制。默认值：三次重试（总共四次尝试）。	image::tickmark.png[]
[id="defaultRequeueRejected"]<<`defaultRequeueRejected`,defaultRequeueRejected>> (requeue-rejected)	判别是否重新排队由于侦听器抛出异常而被拒绝的消息。默认值：`true`。	image::tickmark.png[]	image::tickmark.png[]
[id="errorHandler"]<<`errorHandler`,errorHandler>> (error-handler)	引用`ErrorHandler`策略来处理消息侦听器执行期间可能发生的任何未捕获异常。默认值：`ConditionalRejectingErrorHandler`	image::tickmark.png[]	image::tickmark.png[]
[id="exclusive"]<<`exclusive`,exclusive>> (exclusive)	判别此容器中的单个消费者是否有对队列的独占访问权。当独占访问权为`true`时，容器的并发性必须为 1。如果其他消费者具有独占访问权，容器会尝试根据`recovery-interval`或`recovery-back-off`恢复消费者。当使用命名空间时，此属性会与队列名称一同出现在`<rabbit:listener/>`元素上。默认值：`false`。	image::tickmark.png[]	image::tickmark.png[]
[id="exclusiveConsumerExceptionLogger"]<<`exclusiveConsumerExceptionLogger`,exclusiveConsumerExceptionLogger>> (N/A)	独占消费者无法访问队列时使用的异常记录器。默认情况下，这会在`WARN`级别记录。	image::tickmark.png[]	image::tickmark.png[]
[id="failedDeclarationRetryInterval"]<<`failedDeclarationRetryInterval`,failedDeclarationRetryInterval>> (failed-declaration -retry-interval)	重复进行被动队列申报尝试之间的间隔。被动队列申报发生在消费者启动时，或在从多个队列进行消费但所有队列在初始化期间不可用时。默认值：5000（五秒）。	image::tickmark.png[]	image::tickmark.png[]
[id="forceCloseChannel"]<<`forceCloseChannel`,forceCloseChannel>> (N/A)	如果消费者在`shutdownTimeout`内未响应关闭操作，如果这是`true`，通道会关闭，从而导致所有未确认的消息被重新排队。自 2.0 起，默认值为`true`。可以将其设置为`false`以还原为之前的行为。	image::tickmark.png[]	image::tickmark.png[]
[id="forceStop"]<<`forceStop`,forceStop>> (N/A)	设为 true 以在处理完当前记录后停止（当容器停止时）；导致所有预提取的消息被重新排队。默认情况下，容器将在停止之前取消消费者并处理所有预提取的消息。自版本 2.4.14、3.0.6 开始。默认值：`false`。	image::tickmark.png[]	image::tickmark.png[]
[id="globalQos"]<<`globalQos`,globalQos>> (global-qos)	为 true 时，prefetchCount`全局应用于通道，而不是通道上的每个消费者。有关更多信息，请参见 link:https://www.rabbitmq.com/amqp-0-9-1-reference.html#basic.qos.global[`basicQos.global。	image::tickmark.png[]	image::tickmark.png[]
(group)	仅在使用命名空间时才提供。当指定时，将使用此名称注册`Collection<MessageListenerContainer>`类型的 Bean，并且每个`<listener/>`元素的容器会添加到该集合中。这允许通过迭代集合来启动和停止容器组。如果多个`<listener-container/>`元素具有相同组值，则集合中的容器将形成所有指定容器的聚合。	image::tickmark.png[]	image::tickmark.png[]
[id="idleEventInterval"]<<`idleEventInterval`,idleEventInterval>> (idle-event-interval)	请参阅 Detecting Idle Asynchronous Consumers。	image::tickmark.png[]	image::tickmark.png[]
[id="javaLangErrorHandler"]<<`javaLangErrorHandler`,javaLangErrorHandler>> (N/A)	AbstractMessageListenerContainer.JavaLangErrorHandler`实现，当容器线程捕获`Error`时调用该实现。默认实现调用`System.exit(99)；若要还原为之前的行为（不执行任何操作），请添加一个无操作处理程序。	image::tickmark.png[]	image::tickmark.png[]
[id="maxConcurrentConsumers"]<<`maxConcurrentConsumers`,maxConcurrentConsumers>> (max-concurrency)	如果需要，按需启动的最大并行使用者数。必须大于或等于“concurrentConsumers”。请参阅 Listener Concurrency。	image::tickmark.png[]
[id="messagesPerAck"]<<`messagesPerAck`,messagesPerAck>> (N/A)	确认之间接收消息的数量。使用此项可减少发送到代理的确认数（以增加重新交付消息的可能性为代价）。通常，仅应在高容量侦听器容器上设置此属性。如果设置此属性并拒绝消息（抛出异常），则会确认待处理的确认，并拒绝失败的消息。在事务通道中不允许这样做。如果`prefetchCount`小于`messagesPerAck`，则将其增加到与`messagesPerAck`匹配。默认值：对每条消息进行确认。另请参阅此表中的`ackTimeout`。		image::tickmark.png[]
[id="mismatchedQueuesFatal"]<<`mismatchedQueuesFatal`,mismatchedQueuesFatal>> (mismatched-queues-fatal)	如果此属性在容器启动时为 `true`（默认值：`false`），则容器将检查上下文中声明的所有队列是否与代理上的现有队列兼容。如果存在不匹配的属性（如 `auto-delete`）或参数（如 `x-message-ttl`），则容器（和应用程序上下文）将因致命异常而无法启动。如果在恢复期间检测到问题（例如，在连接丢失后），则容器将停止。应用程序上下文中必须有单个 `RabbitAdmin`（或者通过使用 `rabbitAdmin` 属性在容器上专门配置一个 `RabbitAdmin`）。否则，此属性必须为 `false`。[NOTE]======如果代理在初始启动期间不可用，则容器将启动，并在建立连接时检查条件。======[style="IMPORTANT"]======针对上下文中所有队列进行检查，而不仅仅是针对特定侦听器配置为使用的队列进行检查。如果您希望将检查限制为容器使用的队列，则您应该为容器配置单独的 `RabbitAdmin`，并使用 `rabbitAdmin` 属性提供对它的引用。请参阅 Conditional Declaration 了解更多信息。======[style="IMPORTANT"]======在启动标记为 `@Lazy` 的 Bean 中的 `@RabbitListener` 的容器时，不匹配的队列参数检测会被禁用。这是为了避免潜在的死锁，这种死锁可能会将此类容器的启动延迟长达 60 秒。使用延迟侦听器 Bean 的应用程序在获取对延迟 Bean 的引用之前，应检查队列参数。======	image::tickmark.png[]	image::tickmark.png[]
[id="missingQueuesFatal"]<<`missingQueuesFatal`,missingQueuesFatal>> (missing-queues-fatal)	当设置为 `true`（默认值）时，如果代理上没有可用的配置队列，则会被视为致命性错误。这会导致应用程序上下文在启动时无法初始化。另外，如果在容器运行期间删除队列，默认情况下，消费者会尝试三次连接到队列（间隔五秒），并且如果这些尝试失败，则停止容器。之前版本中不支持此配置。当设置为 `false` 时，在尝试三次后，容器会进入恢复模式，类似于其他问题（例如，代理已关闭）一样。容器会尝试根据 `recoveryInterval` 属性恢复。在每次恢复尝试期间，每个消费者会再次尝试四次在五秒内无操作声明队列。此过程会无限期持续下去。还可以使用属性 bean 为所有容器全局设置属性，如下所示：[style="source",language="xml"]----<util:properties id="spring.amqp.global.properties"> <prop key="mlc.missing.queues.fatal"> false </prop></util:properties>----此全局属性不会应用于具有显式设置的 `missingQueuesFatal` 属性的任何容器。可以通过设置以下属性来覆盖默认重试属性（间隔五秒的三次重试）。[style="IMPORTANT"]======在为标记为 `@Lazy` 的 bean 中启动 `@RabbitListener` 的容器时禁用丢失队列检测。这是为了避免潜在死锁，该死锁可能会将此类容器的启动延迟长达 60 秒。使用惰性侦听器 bean 的应用程序应先检查队列，再获取对此惰性 bean 的引用。======	image::tickmark.png[]	image::tickmark.png[]
[id="monitorInterval"]<<`monitorInterval`,monitorInterval>> (monitor-interval)	使用 DMLC，计划在该间隔内调度一个任务，以监视消费者的状态并恢复任何失败的使用者。		image::tickmark.png[]
[id="noLocal"]<<`noLocal`,noLocal>> (N/A)	设置为 `true` 以禁用从服务器向消费者传递在同一通道连接上发布的消息。	image::tickmark.png[]	image::tickmark.png[]
[id="phase"]<<`phase`,phase>> (phase)	当 `autoStartup` 为 `true` 时，此容器应启动和停止的 Lifecycle 阶段。值越低，容器启动越早，停止越晚。默认值为 `Integer.MAX_VALUE`，表示容器尽可能地晚启动，并尽可能快地停止。	image::tickmark.png[]	image::tickmark.png[]
[id="possibleAuthenticationFailureFatal"]<<`possibleAuthenticationFailureFatal`,possibleAuthenticationFailureFatal>> (possible-authentication-failure-fatal)	当设置为 `true`（SMLC 的默认值）时，如果在连接期间抛出 `PossibleAuthenticationFailureException`，则会被视为致命性错误。如果自动启动了容器，这会导致应用程序上下文在启动期间无法初始化。由于 version 2.0.DirectMessageListenerContainer当设置为 `false`（默认值）时，每个消费者将尝试根据 `monitorInterval`.SimpleMessageListenerContainer重新连接。当设置为 `false` 时，在尝试 3 次后，容器将进入恢复模式，类似于出现其他问题（例如，代理已关闭）一样。容器将尝试根据 `recoveryInterval` 属性恢复。在每次恢复尝试期间，每个消费者将再次尝试 4 次以启动。此过程将无限期持续下去。还可以使用属性 bean 为所有容器全局设置属性，如下所示：[style="source",language="xml"]----<util:properties id="spring.amqp.global.properties"> <prop key="mlc.possible.authentication.failure.fatal"> false </prop></util:properties>----此全局属性不会应用于具有显式设置的 `missingQueuesFatal` 属性的任何容器。可以通过使用其后的这些属性来覆盖默认重试属性（间隔 5 秒的三次重试）。	image::tickmark.png[]	image::tickmark.png[]
[id="prefetchCount"]<<`prefetchCount`,prefetchCount>> (prefetch)	每个消费者等待处理的未确认消息数目。此值越大，发送消息的速度越快，但非顺序处理的风险越高。如果 `acknowledgeMode` 为 `NONE`，则忽略此值。如果需要，则增大此值，以匹配 `batchSize` 或 `messagePerAck`。自 2.0 以来，默认值为 250。您可以将其设置为 1，以恢复之前的行为。[style="IMPORTANT"]======在某些场景下，预取值应该较低 - 例如，处理大消息时，特别是如果处理缓慢的话（消息可能会增加客户端进程的大量内存），并且如果需要严格的消息排序（在这种情况下，应将预取值设置回 1）。另外，对于小批量消息和多个消费者（包括单个侦听器容器实例中的并发），您可能希望减少预取，以便在消费者之间更加均匀地分配消息。======另请参阅 `globalQos`。	image::tickmark.png[]	image::tickmark.png[]
[id="rabbitAdmin"]<<`rabbitAdmin`,rabbitAdmin>> (admin)	侦听器容器侦听至少一个自动删除队列，并且在启动期间找不到该队列时，容器会使用 `RabbitAdmin` 声明该队列以及任何相关的绑定和交换。如果配置此类元素使用条件声明（请参阅 Conditional Declaration），则容器必须使用被配置为声明这些元素的管理工具。在此处指定该管理工具。仅当使用具有条件声明的自动删除队列时才需要此项。如果您不希望在启动容器之前声明自动删除队列，请将 `auto-startup` 在管理工具上设置为 `false`。默认值是一个声明所有非条件元素的 `RabbitAdmin`。	image::tickmark.png[]	image::tickmark.png[]
[id="receiveTimeout"]<<`receiveTimeout`,receiveTimeout>> (receive-timeout)	为每个消息等待的最长时间。如果 `acknowledgeMode=NONE`，这几乎没有效果——容器旋转并请求另一条消息。它对带有 `batchSize > 1` 的事务性 `Channel` 影响最大，因为它会导致在超时到期之前不确认已经消费的消息。当 `consumerBatchEnabled` 为 true 时，如果在批处理完成之前发生此超时，将传递部分批处理。	image::tickmark.png[]
[id="batchReceiveTimeout"]<<`batchReceiveTimeout`,batchReceiveTimeout>> (batch-receive-timeout)	为收集批处理消息而超时的小时数。它限制了填充 batchSize 的等待时间。当 `batchSize > 1` 且收集批处理消息的时间大于 `batchReceiveTime` 时，将传递批处理。默认为 0（无超时）。	image::tickmark.png[]
[id="recoveryBackOff"]<<`recoveryBackOff`,recoveryBackOff>> (recovery-back-off)	指定 `BackOff` 以间隔尝试启动消费者（如果它因非致命原因启动失败）。默认值是 `FixedBackOff`，在五秒内无限次重试。与 `recoveryInterval` 互斥。	image::tickmark.png[]	image::tickmark.png[]
[id="recoveryInterval"]<<`recoveryInterval`,recoveryInterval>> (recovery-interval)	确定如果使用者因非致命原因启动失败时，尝试启动使用者的间隔时间（毫秒）。默认值：5000。与 `recoveryBackOff` 互斥。	image::tickmark.png[]	image::tickmark.png[]
[id="retryDeclarationInterval"]<<`retryDeclarationInterval`,retryDeclarationInterval>> (missing-queue- retry-interval)	如果在使用者初始化期间存在一部分已配置队列，则使用者开始消耗这些队列中的消息。使用者尝试使用此间隔被动声明丢失的队列。当此间隔过去时，“declarationRetries”和“failedDeclarationRetryInterval”将再次使用。如果仍有丢失的队列，则使用者再次等待此间隔然后再重试。此过程无限地继续，直到所有队列都可用。默认值：60000（一分钟）。	image::tickmark.png[]
[id="shutdownTimeout"]<<`shutdownTimeout`,shutdownTimeout>> (N/A)	当某个容器关闭时（例如，如果其封闭的 `ApplicationContext` 被关闭），它会等待处理中的消息被处理到这个限制。默认设置为五秒。	image::tickmark.png[]	image::tickmark.png[]
[id="startConsumerMinInterval"]<<`startConsumerMinInterval`,startConsumerMinInterval>> (min-start-interval)	必须经过的毫秒数，然后根据需求启动每个新消费者。请参阅 Listener Concurrency。默认值：10000（10 秒）。	image::tickmark.png[]
[id="statefulRetryFatal"]<<`statefulRetryFatal`,statefulRetryFatal>> WithNullMessageId (N/A)	在使用有状态重试建议时，如果收到一条缺少 `messageId` 属性的消息，它会被认为对于使用者是致命的，默认情况下，该使用者会停止。将此设置为 `false` 以放弃此类消息（或将其路由到死信队列）。	image::tickmark.png[]	image::tickmark.png[]
[id="stopConsumerMinInterval"]<<`stopConsumerMinInterval`,stopConsumerMinInterval>> (min-stop-interval)	在检测到空闲消费者之前，从停止上一个消费者以来必需经过的毫秒数。请参阅 Listener Concurrency。默认值：60000（一分钟）。	image::tickmark.png[]
[id="streamConverter"]<<`streamConverter`,streamConverter>> (N/A)	一个 `StreamMessageConverter`，用于将本机流消息转换为 Spring AMQP 消息。			image::tickmark.png[]
[id="taskExecutor"]<<`taskExecutor`,taskExecutor>> (task-executor)	一个对 Spring `TaskExecutor`（或标准 JDK 1.5+ `Executor`）的引用，用于执行监听器调用器。默认值为 `SimpleAsyncTaskExecutor`，使用内部管理的线程。	image::tickmark.png[]	image::tickmark.png[]
[id="taskScheduler"]<<`taskScheduler`,taskScheduler>> (task-scheduler)	借助 DMLC，调度程序以“monitorInterval”运行监控任务。		image::tickmark.png[]
[id="transactionManager"]<<`transactionManager`,transactionManager>> (transaction-manager)	操作监听器的外部事务管理器。也补充 `channelTransacted` — 如果 `Channel` 被作为事务处理，它的事务将与外部事务同步。	image::tickmark.png[]	image::tickmark.png[]