Kafka pollable consumers lose ConsumerFactory listeners when max.poll.records is greater than one
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 55/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- backend, distributed-systems, observability
Hướng nghiên cứu
Start by reading Spring Integration Kafka's KafkaMessageSource, where the issue says a replacement DefaultKafkaConsumerFactory is created when max.poll.records is missing or greater than 1. Check how that replacement handles the original factory's listeners, then run the linked reproducer's SpringCloudStreamPollableKafkaMetricsTests to compare the two configurations. Done means the listener is preserved and native kafka.consumer.* meters register with either setting.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Thanks for considering raising a Spring Cloud Stream issue.
Describe the issue
Kafka pollable consumers lose ConsumerFactory.Listener instances when max.poll.records is not set to 1.
This prevents Micrometer native Kafka metrics from being registered for the consumer created by KafkaMessageSource.
The issue is visible through Spring Cloud Stream, but the suspected root cause appears to be in Spring Integration Kafka's KafkaMessageSource.
To Reproduce
The issue can be reproduced with this standalone demo application:
https://github.com/ferblaca/demoStreamPollable
The reproducer uses:
- Spring Boot 4.1.2;
- Spring Cloud Stream 5.0.4;
- the Spring Cloud Stream Kafka binder;
- a real Kafka broker started with Testcontainers;
- two Spring Cloud Stream pollable consumers.
Steps:
-
Clone the repository:
git clone https://github.com/ferblaca/demoStreamPollable.git cd demoStreamPollable -
Run the reproducer test:
./mvnw -B -Dtest=SpringCloudStreamPollableKafkaMetricsTests test -
Review the test implementation:
src/test/java/com/example/demoStreamPollable/SpringCloudStreamPollableKafkaMetricsTests.java -
The test creates two pollable bindings:
pollableInput-in-0 pollableInputMaxOne-in-0 -
The first binding is configured with:
spring.cloud.stream.kafka.bindings.pollableInput-in-0.consumer.configuration.max.poll.records=10The test publishes and consumes a real Kafka message through
PollableMessageSource, then verifies that no meter whose name starts withkafka.consumeris registered. -
The second binding is configured with:
spring.cloud.stream.kafka.bindings.pollableInputMaxOne-in-0.consumer.configuration.max.poll.records=1The test publishes and consumes another real Kafka message through a second
PollableMessageSource, then verifies that a meter whose name starts withkafka.consumeris registered.
The test passes and demonstrates the different behavior between both configurations.
Version of the framework
- Spring Boot 4.1.2
- Spring Cloud Stream 5.0.4
- Java 25
- Kafka broker: Testcontainers
apache/kafka-native:3.8.0
Expected behavior
When KafkaMessageSource creates a replacement consumer factory, it should preserve the behavior of the supplied factory, including registered ConsumerFactory.Listener instances such as:
MicrometerConsumerListener
Native kafka.consumer.* metrics should be registered regardless of whether max.poll.records is explicitly set to 1.
Screenshots
Not applicable.
Additional context
Spring Cloud Stream's Kafka binder creates the consumer factory and invokes the registered ClientFactoryCustomizer before creating the pollable source.
The relevant flow is:
KafkaMessageChannelBinder
-> createPolledConsumerResources(...)
-> createKafkaConsumerFactory(...)
-> ClientFactoryCustomizer.configure(consumerFactory)
-> new KafkaMessageSource<>(consumerFactory, consumerProperties)
The customizer adds a MicrometerConsumerListener to the original DefaultKafkaConsumerFactory.
However, when max.poll.records is missing or greater than 1, KafkaMessageSource forces it to 1 by creating a new DefaultKafkaConsumerFactory.
The replacement factory copies the configuration and deserializers, but does not copy the listeners from the original factory. Consequently, the MicrometerConsumerListener is lost before the actual Kafka consumer is created.
The current behavior also logs:
max.poll.records' has been forced from 10 to 1, to avoid having to seek after each record
As a workaround, applications can configure max.poll.records=1 for each pollable Kafka binding. This prevents KafkaMessageSource from creating the replacement factory, but it exposes an internal implementation detail to applications.
Could you please confirm whether this issue should be fixed in:
- Spring Integration Kafka, in
KafkaMessageSource; - Spring Cloud Stream's Kafka binder;
- or both?
The suspected fix is to copy the ConsumerFactory.Listener instances when KafkaMessageSource creates the replacement DefaultKafkaConsumerFactory. The reproducer is intentionally implemented through Spring Cloud Stream so that the behavior can be verified using a real PollableMessageSource and the Kafka binder, but the suspected defect appears to belong to Spring Integration Kafka.
- Ngôn ngữ chính
- Java
- Star
- 1.1k
- Fork
- 651
- Merge trung bình
- 2 ngày 15 giờ
- Pull request đã merge (30 ngày)
- 8
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của spring-cloud/spring-cloud-stream
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
spring-cloud/spring-cloud-stream#3332 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Kafka binder health-check consumer failures return DOWN without logging the exceptionCó thể đã có người làm @Sanskar121543 đã nhận 1 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 25/100
spring-cloud/spring-cloud-stream#3329 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 74/100
spring-cloud/spring-cloud-stream#3316 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
StreamBridge removing BindingProperties leads to wrong destination in ProvisioningProviderCó thể làm lại được @olegz đã nhận 60 ngày trước và không có pull request nào đang mở. Đang mởbug
spring-cloud/spring-cloud-stream#3257 · 6 bình luận · 2 reaction · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
StreamBridge's hashProducerProperties produces hash collisions across different binding names, causing Partition key cannot be nullCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 48/100
spring-cloud/spring-cloud-stream#3242 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của spring-cloud/spring-cloud-stream
Issue tương tự
-
bug key bindings source editor
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Visual COBOL: missing 11.0 and 12.0, and 9.0 date differs from Rocket Software's lifecycle pageĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
endoflife-date/endoflife.date#11561 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 73/100
conductor-oss/conductor#1824 ·
Maintainer thường phản hồi trong vòng 5 ngày
-
Type: Possible bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 66/100
AntennaPod/AntennaPod#8887 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Card-Forge/forge#12710 ·
Maintainer thường phản hồi trong vòng 1 ngày