-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Under-documented "Manually Assigning All Partitions" #2891
Comments
Thanks. The container should detect manual assignment with no group and ignore |
Do you mean that KafkaMessageListenerContainer
should be replaced by
? |
No, we must only skip the commit if the group is null in that case. |
That sounds inconsistent:
If no group + ack is OK, it should be acked always, according to configuration |
I agree; we can change the default behavior in the upcoming 3.1 release (due next week(, but not in earlier versions. |
Resolves spring-projects#2891 When using manual partition assignment and `AckMode.MANUAL`, it is possible to have a `null` `group.id`, whereby Kafka does not maintain any committed offsets. In this case, we should not attempt to commit the offset, even if the error handler `ackAfterHandle` property is true. **cherry-pick to 3.0.x, 2.9.x**
Resolves spring-projects#2891 When using manual partition assignment and `AckMode.MANUAL`, it is possible to have a `null` `group.id`, whereby Kafka does not maintain any committed offsets. In this case, we should not attempt to commit the offset after recovery, even if the error handler `ackAfterHandle` property is true. **cherry-pick to 3.0.x, 2.9.x**
Resolves #2891 When using manual partition assignment and `AckMode.MANUAL`, it is possible to have a `null` `group.id`, whereby Kafka does not maintain any committed offsets. In this case, we should not attempt to commit the offset after recovery, even if the error handler `ackAfterHandle` property is true. **cherry-pick to 3.0.x, 2.9.x**
Resolves #2891 When using manual partition assignment and `AckMode.MANUAL`, it is possible to have a `null` `group.id`, whereby Kafka does not maintain any committed offsets. In this case, we should not attempt to commit the offset after recovery, even if the error handler `ackAfterHandle` property is true. **cherry-pick to 3.0.x, 2.9.x** (cherry picked from commit 9f1050a)
Resolves spring-projects#2891 When using manual partition assignment with `null` `group.id` always coerce `AckMode` to `MANUAL`.
Resolves #2891 When using manual partition assignment and `AckMode.MANUAL`, it is possible to have a `null` `group.id`, whereby Kafka does not maintain any committed offsets. In this case, we should not attempt to commit the offset after recovery, even if the error handler `ackAfterHandle` property is true. **cherry-pick to 3.0.x, 2.9.x** (cherry picked from commit 9f1050a) # Conflicts: # spring-kafka/src/main/java/org/springframework/kafka/listener/KafkaMessageListenerContainer.java
Resolves #2891 When using manual partition assignment with `null` `group.id` always coerce `AckMode` to `MANUAL`.
Related to spring-projects/spring-kafka#2891 Starting with Spring for Apache Kafka `3.1`, the `ackMode` for listener container is coerced to `MANUAL` if no `groupId` assigned
In what version(s) of Spring for Apache Kafka are you seeing this issue?
3.0.12
Describe the bug
Doc says
That is not enough, because DefaultErrorHandler by default has
ackAfterHandle == true
and commit the offset on exception.Should I create and Doc PR to mention
?
To be honest, preventing the container from committing offsets should work automatically when
@TopicPartition
is detected...The text was updated successfully, but these errors were encountered: