You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Resolves#2239
* GH-2239: Replace PartitionPausingBackOffManager
New back of manager (and factory) that uses a task scheduler to resume
the paused partitions.
Revert change to deprecated PartitionPausingBackoffManager.
Log resume.
* Remove legacy code.
Also fix unrelated race in EKIT.
Only allow one `RetryTemplateConfigurationSupport` bean.
* Fix static var.
* Docs.
* More docs.
* Remove more dead/deprecated code.
* Address PR Comments.
* Fix RetryTopicConfigurer bean retrieval.
* Remove unnecessary casts in doc.
# Conflicts:
# spring-kafka/src/main/java/org/springframework/kafka/retrytopic/RetryTopicConfigurer.java
# spring-kafka/src/main/java/org/springframework/kafka/retrytopic/RetryTopicInternalBeanNames.java
# spring-kafka/src/test/java/org/springframework/kafka/retrytopic/ListenerContainerFactoryConfigurerTests.java
Copy file name to clipboardExpand all lines: spring-kafka-docs/src/main/asciidoc/kafka.adoc
+1-1
Original file line number
Diff line number
Diff line change
@@ -5137,7 +5137,7 @@ This new error handler replaces the `SeekToCurrentErrorHandler` and `RecoveringB
5137
5137
One difference is that the fallback behavior for batch listeners (when an exception other than a `BatchListenerFailedException` is thrown) is the equivalent of the <<retrying-batch-eh>>.
5138
5138
5139
5139
IMPORTANT: Starting with version 2.9, the `DefaultErrorHandler` can be configured to provide the same semantics as seeking the unprocessed record offsets as discussed below, but without actually seeking.
5140
-
Instead, the records are retained by the listener container and resubmitted to the listener after the error handler exits (and after performing a single paused `poll()`, to keep the consumer alive).
5140
+
Instead, the records are retained by the listener container and resubmitted to the listener after the error handler exits (and after performing a single paused `poll()`, to keep the consumer alive; if <<retry-topic>> or a `ContainerPausingBackOffHandler` are being used, the pause may extend over multiple polls).
5141
5141
The error handler returns a result to the container that indicates whether the current failing record can be resubmitted, or if it was recovered and then it will not be sent to the listener again.
5142
5142
To enable this mode, set the property `seekAfterError` to `false`.
Copy file name to clipboardExpand all lines: spring-kafka-docs/src/main/asciidoc/retrytopic.adoc
+29-21
Original file line number
Diff line number
Diff line change
@@ -5,6 +5,10 @@ IMPORTANT: This is an experimental feature and the usual rule of no breaking API
5
5
Users are encouraged to try out the feature and provide feedback via GitHub Issues or GitHub discussions.
6
6
This is regarding the API only; the feature is considered to be complete, and robust.
7
7
8
+
Version 2.9 changed the mechanism to bootstrap infrastructure beans; see <<retry-config>> for the two mechanisms that are now required to bootstrap the feature.
9
+
10
+
After these changes, we are intending to remove the experimental designation, probably in version 3.0.
11
+
8
12
Achieving non-blocking retry / dlt functionality with Kafka usually requires setting up extra topics and creating and configuring the corresponding listeners.
9
13
Since 2.7 Spring for Apache Kafka offers support for that via the `@RetryableTopic` annotation and `RetryTopicConfiguration` class to simplify that bootstrapping.
10
14
@@ -33,28 +37,23 @@ If one message's processing takes longer than the next message's back off period
33
37
Also, for short delays (about 1s or less), the maintenance work the thread has to do, such as committing offsets, may delay the message processing execution.
34
38
The precision can also be affected if the retry topic's consumer is handling more than one partition, because we rely on waking up the consumer from polling and having full pollTimeouts to make timing adjustments.
35
39
36
-
That being said, for consumers handling a single partition the message's processing should happen under 100ms after it's exact due time for most situations.
40
+
That being said, for consumers handling a single partition the message's processing should occur approximately at its exact due time for most situations.
37
41
38
42
IMPORTANT: It is guaranteed that a message will never be processed before its due time.
39
43
40
-
===== Tuning the Delay Precision
41
-
42
-
The message's processing delay precision relies on two `ContainerProperties`: `ContainerProperties.pollTimeout` and `ContainerProperties.idlePartitionEventInterval`.
43
-
Both properties will be automatically set in the retry topic and dlt's `ListenerContainerFactory` to one quarter of the smallest delay value for that topic, with a minimum value of 250ms and a maximum value of 5000ms.
44
-
These values will only be set if the property has its default values - if you change either value yourself your change will not be overridden.
45
-
This way you can tune the precision and performance for the retry topics if you need to.
46
-
47
-
NOTE: You can have separate `ListenerContainerFactory` instances for the main and retry topics - this way you can have different settings to better suit your needs, such as having a higher polling timeout setting for the main topics and a lower one for the retry topics.
48
-
44
+
[[retry-config]]
49
45
==== Configuration
50
46
51
-
Starting with version 2.9, the `@EnableKafkaRetryTopic` annotation should be used in a `@Configuration` annotated class.
47
+
Starting with version 2.9, for default configuration, the `@EnableKafkaRetryTopic` annotation should be used in a `@Configuration` annotated class.
52
48
This enables the feature to bootstrap properly and gives access to injecting some of the feature's components to be looked up at runtime.
53
-
Also, to configure the feature's components and global features, the `RetryTopicConfigurationSupport` class should be extended in a `@Configuration` class, and the appropriate methods overridden.
54
-
For more details refer to <<retry-topic-global-settings>>.
55
49
56
50
NOTE: It is not necessary to also add `@EnableKafka`, if you add this annotation, because `@EnableKafkaRetryTopic` is meta-annotated with `@EnableKafka`.
57
51
52
+
Also, starting with that version, for more advanced configuration of the feature's components and global features, the `RetryTopicConfigurationSupport` class should be extended in a `@Configuration` class, and the appropriate methods overridden.
53
+
For more details refer to <<retry-topic-global-settings>>.
54
+
55
+
IMPORTANT: Only one of the above techniques can be used, and only one `@Configuration` class can extend `RetryTopicConfigurationSupport`.
56
+
58
57
===== Using the `@RetryableTopic` annotation
59
58
60
59
To configure the retry topic and dlt for a `@KafkaListener` annotated method, you just have to add the `@RetryableTopic` annotation to it and Spring for Apache Kafka will bootstrap all the necessary topics and consumers with the default configurations.
@@ -161,9 +160,9 @@ It's best to use a single `RetryTopicConfiguration` bean for configuration of su
161
160
[[retry-topic-global-settings]]
162
161
===== Configuring Global Settings and Features
163
162
164
-
Since 2.9, the previous bean overriding approach for configuring components has been deprecated.
165
-
This does not change the `RetryTopicConfiguration` beans approach - only components' configurations.
166
-
Now the `RetryTopicConfigurationSupport` class should be extended in a `@Configuration` class, and the proper methods overridden.
163
+
Since 2.9, the previous bean overriding approach for configuring components has been removed (without deprecation, due to the aforementioned experimental nature of the API).
164
+
This does not change the `RetryTopicConfiguration` beans approach - only infrastructure components' configurations.
165
+
Now the `RetryTopicConfigurationSupport` class should be extended in a (single) `@Configuration` class, and the proper methods overridden.
167
166
An example follows:
168
167
169
168
====
@@ -185,6 +184,15 @@ public class MyRetryTopicConfiguration extends RetryTopicConfigurationSupport {
Copy file name to clipboardExpand all lines: spring-kafka/src/main/java/org/springframework/kafka/annotation/KafkaListenerAnnotationBeanPostProcessor.java
0 commit comments