没有 SeekToCurrentErrorHandler 的 DeadLetterPublishingRecoverer
DeadLetterPublishingRecoverer without SeekToCurrentErrorHandler
我有一个非常简单的用例。我有一个 Kafka 消费者，我想将所有无效或部分消息移至死信队列。文档中的示例使用 SeekToCurrentErrorHandler 并附加 DeadLetterPublishingRecoverer。就我而言，我不想重试这些无效消息，我已将 maxFailures 设置为 1 （我也尝试了 0，结果相同）。这里的问题是，出于某种原因 SeekToCurrentErrorHandler 每次我收到无效消息时都会寻找分区，即使我只想将其移动到 DLT，这使得整个过程非常缓慢。我不确定 SeekToCurrentErrorHandler 的这种行为是否正确，但如果没有 SeekToCurrentErrorHandler，是否还有更好的方法来实现我的目标？我必须创建自定义 ErrorHandler 吗？
P.S.
当无效消息多于消费者可以缓冲时，观察到 SeekToCurrentErrorHandler 的奇怪行为。如果有几条消息，一切都很快，但是当我们有大量无效消息时，它的性能就很糟糕了。
这是一个错误 - 它是 fixed on master and 2.2.x。它将出现在下周发布的 2.2.5 版本中。
The SeekToCurrentErrorHandler and DefaultAfterRollbackProcessor
always retried at least one time, even if maxAttempts was 1.
我有一个非常简单的用例。我有一个 Kafka 消费者，我想将所有无效或部分消息移至死信队列。文档中的示例使用 SeekToCurrentErrorHandler 并附加 DeadLetterPublishingRecoverer。就我而言，我不想重试这些无效消息，我已将 maxFailures 设置为 1 （我也尝试了 0，结果相同）。这里的问题是，出于某种原因 SeekToCurrentErrorHandler 每次我收到无效消息时都会寻找分区，即使我只想将其移动到 DLT，这使得整个过程非常缓慢。我不确定 SeekToCurrentErrorHandler 的这种行为是否正确，但如果没有 SeekToCurrentErrorHandler，是否还有更好的方法来实现我的目标？我必须创建自定义 ErrorHandler 吗？
P.S.
当无效消息多于消费者可以缓冲时，观察到 SeekToCurrentErrorHandler 的奇怪行为。如果有几条消息，一切都很快，但是当我们有大量无效消息时，它的性能就很糟糕了。
这是一个错误 - 它是 fixed on master and 2.2.x。它将出现在下周发布的 2.2.5 版本中。
The
SeekToCurrentErrorHandlerandDefaultAfterRollbackProcessoralways retried at least one time, even ifmaxAttemptswas 1.