|
1 | 1 | = What's new? |
2 | 2 |
|
3 | | -[[what-s-new-in-3-2-since-3-1]] |
4 | | -== What's New in 3.2 Since 3.1 |
| 3 | +[[what-s-new-in-3-3-since-3-2]] |
| 4 | +== What's New in 3.3 Since 3.2 |
5 | 5 | :page-section-summary-toc: 1 |
6 | 6 |
|
7 | | -This section covers the changes made from version 3.1 to version 3.2. |
| 7 | +This section covers the changes made from version 3.2 to version 3.3. |
8 | 8 | For changes in earlier version, see xref:appendix/change-history.adoc[Change History]. |
9 | 9 |
|
10 | | -[[x32-kafka-client-version]] |
11 | | -=== Kafka Client Version |
12 | | - |
13 | | -This version requires 3.7.0 `kafka-clients`. |
14 | | -The 3.7.0 version of Kafka client introduces the new consumer group protocol. |
15 | | -Fore more details and it's limitations see https://cwiki.apache.org/confluence/display/KAFKA/The+Next+Generation+of+the+Consumer+Rebalance+Protocol+%28KIP-848%29+-+Early+Access+Release+Notes[KIP-848]. |
16 | | -The new consumer group protocol is an early access release and not meant to be used in production. |
17 | | -It is only recommended to use for testing purposes in this version. |
18 | | -Therefore, Spring for Apache Kafka supports this new consumer group protocol only to the extent of such testing level support available in the `kafka-client` itself. |
19 | | -By default, Spring for Apache Kafka uses the classic consumer group protocol and when testing the new consumer group protocol, that needs to be opted-in via the `group.protocol` property on the consumer. |
20 | | - |
21 | | -[[x32-testing-support-changes]] |
22 | | -=== Testing Support Changes |
23 | | - |
24 | | -The `kraft` mode is disabled in `EmbeddedKafka` by default and users wanting to use the `kraft` mode must enable it. |
25 | | -This is due to certain instabilities observed while using `EmbeddedKafka` in `kraft` mode, especially when testing the new consumer group protocol. |
26 | | -The new consumer group protocol is only supported in `kraft` mode and because of this, when testing the new protocol, that needs to be done against a real Kafka cluster and not the one based on the `KafkaClusterTestKit`, which `EmbeddedKafka` is based upon. |
27 | | -In addition, there were some other race conditions observed, while running multiple `KafkaListener` methods with `EmbeddedKafka` in `kraft` mode. |
28 | | -Until these issues are resolved, the `kraft` default on `EmbeddedKafka` will remain as `false`. |
29 | | - |
30 | | -[[x32-kafka-streams-iqs-support]] |
31 | | -=== Kafka Streams Interactive Query Support |
32 | | - |
33 | | -A new API `KafkaStreamsInteractiveQuerySupport` for accessing queryable stores used in Kafka Streams interactive queries. |
34 | | -See xref:streams.adoc#kafka-streams-iq-support[Kafka Streams Interactive Support] for more details. |
35 | | - |
36 | | -[[x32-tiss]] |
37 | | -=== TransactionIdSuffixStrategy |
38 | | - |
39 | | -A new `TransactionIdSuffixStrategy` interface was introduced to manage `transactional.id` suffix. |
40 | | -The default implementation is `DefaultTransactionIdSuffixStrategy` when setting `maxCache` greater than zero can reuse `transactional.id` within a specific range, otherwise suffixes will be generated on the fly by incrementing a counter. |
41 | | -See xref:kafka/transactions.adoc#transaction-id-suffix-fixed[Fixed TransactionIdSuffix] for more information. |
42 | | - |
43 | | -[[x32-async-return]] |
44 | | -=== Async @KafkaListener Return |
45 | | - |
46 | | -`@KafkaListener` (and `@KafkaHandler`) methods can now return asynchronous return types include `CompletableFuture<?>`, `Mono<?>` and Kotlin `suspend` functions. |
47 | | -See xref:kafka/receiving-messages/async-returns.adoc[Async Returns] for more information. |
48 | | - |
49 | | -[[x32-customizable-dlt-routing]] |
50 | | -=== Routing of messages to custom DLTs based on thrown exceptions |
51 | | - |
52 | | -It's now possible to redirect messages to the custom DLTs based on the type of the exception, which has been thrown during the message processing. |
53 | | -Rules for the redirection are set either via the `RetryableTopic.exceptionBasedDltRouting` or the `RetryTopicConfigurationBuilder.dltRoutingRules`. |
54 | | -Custom DLTs are created automatically as well as other retry and dead-letter topics. |
55 | | -See xref:retrytopic/features.adoc#exc-based-custom-dlt-routing[Routing of messages to custom DLTs based on thrown exceptions] for more information. |
56 | | - |
57 | | -[[x32-cp-ptm]] |
58 | | -=== Deprecating ContainerProperties transactionManager property |
59 | | - |
60 | | -Deprecating the `transactionManager` property in `ContainerProperties` in favor of `KafkaAwareTransactionManager`, a narrower type compared to the general `PlatformTransactionManager`. See xref:kafka/container-props.adoc#kafkaAwareTransactionManager[ContainerProperties] and xref:kafka/transactions.adoc#transaction-synchronization[Transaction Synchronization]. |
61 | | - |
62 | | -[[x32-after-rollback-processing]] |
63 | | -=== After Rollback Processing |
64 | | - |
65 | | -A new `AfterRollbackProcessor` API `processBatch` is provided. |
66 | | -See xref:kafka/annotation-error-handling.adoc#after-rollback[After-rollback Processor] for more information. |
67 | | - |
68 | | -[[x32-retry-topic]] |
69 | | -=== Change @RetryableTopic SameIntervalTopicReuseStrategy default value |
70 | | -Change `@RetryableTopic` property `SameIntervalTopicReuseStrategy` default value to `SINGLE_TOPIC`. |
71 | | -See xref:retrytopic/topic-naming.adoc#single-topic-maxinterval-delay[Single Topic for maxInterval Exponential Delay]. |
72 | | - |
73 | | -=== Non-blocking retries support class level @KafkaListener |
74 | | -Non-blocking retries support xref:kafka/receiving-messages/class-level-kafkalistener.adoc[@KafkaListener on a Class]. |
75 | | -See xref:retrytopic.adoc[Non-Blocking Retries]. |
76 | | - |
77 | | -=== Support process @RetryableTopic on a class in RetryTopicConfigurationProvider. |
78 | | -Provides a new public API to find `RetryTopicConfiguration`. |
79 | | -See xref:retrytopic/retry-config.adoc#find-retry-topic-config[Find RetryTopicConfiguration] |
80 | | - |
81 | | -=== RetryTopicConfigurer support process MultiMethodKafkaListenerEndpoint. |
82 | | -The `RetryTopicConfigurer` support process and register `MultiMethodKafkaListenerEndpoint`. |
83 | | -The `MultiMethodKafkaListenerEndpoint` provides `getter/setter` for properties `defaultMethod` and `methods`. |
84 | | -Modify the `EndpointCustomizer` that strictly for `MethodKafkaListenerEndpoint` types. |
85 | | -The `EndpointHandlerMethod` add new constructors construct an instance for the provided bean. |
86 | | -Provides new class `EndpointHandlerMultiMethod` to handler multi method for retrying endpoints. |
87 | | - |
88 | | -[[x32-seek-offset-compute-fn]] |
89 | | -=== New API method to seek to an offset based on a user provided function |
90 | | -`ConsumerCallback` provides a new API to seek to an offset based on a user-defined function, which takes the current offset in the consumer as an argument. |
91 | | -See xref:kafka/seek.adoc#seek[Seek API Docs] for more details. |
92 | | - |
93 | | -[[x32-annotation-partition-offset-seek-position]] |
94 | | -=== @PartitionOffset support for SeekPosition |
95 | | -Adding `seekPosition` property to `@PartitionOffset` support for `TopicPartitionOffset.SeekPosition`. |
96 | | -See xref:kafka/receiving-messages/listener-annotation.adoc#manual-assignment[manual-assignment] for more details. |
97 | | - |
98 | | -[[x32-topic-partition-offset-constructor]] |
99 | | -=== New constructor in TopicPartitionOffset that accepts a function to compute the offset to seek to |
100 | | -`TopicPartitionOffset` has a new constructor that takes a user-provided function to compute the offset to seek to. |
101 | | -When this constructor is used, the framework calls the function with the input argument of the current consumer offset position. |
102 | | -See xref:kafka/seek.adoc#seek[Seek API Docs] for more details. |
103 | | - |
104 | | -[[x32-default-clientid-prefix]] |
105 | | -=== Spring Boot application name as default client ID prefix |
106 | | - |
107 | | -For Spring Boot applications which define an application name, this name is now used |
108 | | -as a default prefix for auto-generated client IDs for certain client types. |
109 | | -See xref:kafka/connecting.adoc#default-client-id-prefixes[Default client ID prefixes] for more details. |
110 | | - |
111 | | -[[get-listener-containers-matching]] |
112 | | -== Enhanced Retrieval of MessageListenerContainers |
113 | | - |
114 | | -`ListenerContainerRegistry` provides two new API's dynamically find and filter `MessageListenerContainer` instances. |
115 | | -`getListenerContainersMatching(Predicate<String> idMatcher)` to filter by ID and the other is |
116 | | -`getListenerContainersMatching(BiPredicate<String, MessageListenerContainer> matcher)` to filter by ID and container properties. |
117 | | - |
118 | | -See xref:kafka/receiving-messages/kafkalistener-lifecycle.adoc#retrieving-message-listener-containers[`@KafkaListener` Lifecycle Management's API Docs] for more information. |
119 | | - |
120 | | -[[x32-observation]] |
121 | | -== Enhanced observation by providing more tracing tags |
122 | | - |
123 | | -`KafkaTemplateObservation` provides more tracing tags(low cardinality). |
124 | | -`KafkaListenerObservation` provides a new API to find high cardinality key names and more tracing tags(high or low cardinality). |
125 | | -See xref:kafka/micrometer.adoc#observation[Micrometer Observation] |
0 commit comments