2. What’s new?
2.1. What’s New in 3.0 Since 2.9
This section covers the changes made from version 2.9 to version 3.0. For changes in earlier version, see Change History.
2.1.2. Exactly Once Semantics
EOSMode.V1
(aka ALPHA
) is no longer supported.
When using transactions, the minimum broker version is 2.5. |
See Exactly Once Semantics and KIP-447 for more information.
2.1.3. Observation
Enabling observation for timers and tracing using Micrometer is now supported. See Micrometer Observation for more information.
2.1.4. Native Images
Support for creating native images is provided. See Native Images for more information.
2.1.5. Global Single Embedded Kafka
The embedded Kafka (EmbeddedKafkaBroker
) can now be start as a single global instance for the whole test plan.
See Using the Same Broker(s) for Multiple Test Classes for more information.
2.1.6. Retryable Topics Changes
This feature is no longer considered experimental (as far as its API is concerned), the feature itself has been supported since 2.7, but with a greater than normal possibility of breaking API changes.
The bootstrapping of Non-Blocking Retries infrastructure beans has changed in this release to avoid some timing problems that occurred in some application regarding application initialization.
You can now set a different concurrency
for the retry containers; by default, the concurrency is the same as the main container.
@RetryableTopic
can now be used as a meta-annotation on custom annotations, including support for @AliasFor
properties.
See Configuration for more information.
The default replication factor for the retry topics is now -1
(use broker default).
If your broker is earlier that version 2.4, you will now need to explicitly set the property.
You can now configure multiple @RetryableTopic
listeners on the same topic in the same application context.
Previously, this was not possible.
See Multiple Listeners, Same Topic(s) for more information.
There are breaking API changes in RetryTopicConfigurationSupport
; specifically, if you override the bean definition methods for destinationTopicResolver
, kafkaConsumerBackoffManager
and/or retryTopicConfigurer
;
these methods now require an ObjectProvider<RetryTopicComponentFactory>
parameter.
2.1.7. Listener Container Changes
Events related to consumer authentication and authorization failures are now published by the container. See Application Events for more information.
You can now customize the thread names used by consumer threads. See Container Thread Naming for more information.
The container property restartAfterAuthException
has been added.
See Listener Container Properties for more information.
2.1.8. KafkaTemplate
Changes
The futures returned by this class are now CompletableFuture
s instead of ListenableFuture
s.
See Using KafkaTemplate
.
2.1.9. ReplyingKafkaTemplate
Changes
The futures returned by this class are now CompletableFuture
s instead of ListenableFuture
s.
See Using ReplyingKafkaTemplate
and Request/Reply with Message<?>
s.
2.1.10. @KafkaListener
Changes
You can now use a custom correlation header which will be echoed in any reply message.
See the note at the end of Using ReplyingKafkaTemplate
for more information.
You can now manually commit parts of a batch before the entire batch is processed. See Committing Offsets for more information.
2.1.11. KafkaHeaders
Changes
Four constants in KafkaHeaders
that were deprecated in 2.9.x have now been removed.
-
Instead of
MESSAGE_KEY
, useKEY
. -
Instead of
PARTITION_ID
, usePARTITION
Similarly, RECEIVED_MESSAGE_KEY
is replaced by RECEIVED_KEY
and RECEIVED_PARTITION_ID
is replaced by RECEIVED_PARTITION
.
2.1.12. Testing Changes
Version 3.0.7 introduced a MockConsumerFactory
and MockProducerFactory
.
See Mock Consumer and Producer for more information.
Starting with version 3.0.10, the embedded Kafka broker, by default, sets the Spring Boot property spring.kafka.bootstrap-servers
to the address(es) of the embedded broker(s).
2.2. JsonDeserializer (Since 3.0.12)
When a deserialization exception occurs, the SerializationException
message no longer contains the data with the form Can’t deserialize data [[123, 34, 98, 97, 122, …
; an array of numerical values for each data byte is not useful and can be verbose for large data.
When used with an ErrorHandlingDeserializer
, the DeserializationException
sent to the error handler contains the data
property which contains the raw data that could not be deserialized.
When not used with an ErrorHandlingDeserializer
, the KafkaConsumer
will continually emit exceptions for the same record showing the topic/partition/offset and the cause thrown by Jackson.