Skip to content

KAFKA-19062: Port changes from KAFKA-18645 to share-consumers #19335

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

Merged
merged 2 commits into from
Apr 1, 2025

Conversation

ShivsundarR
Copy link
Collaborator

@ShivsundarR ShivsundarR commented Apr 1, 2025

https://issues.apache.org/jira/browse/KAFKA-19062

  • After 6636316 , we handle the close timeout in AsyncKafkaConsumer by taking the minimum of user given timeout and the default request timeout config.

  • These changes need to applied to ShareConsumers as well.

@github-actions github-actions bot added consumer clients small Small PRs triage PRs from the community labels Apr 1, 2025
@ShivsundarR ShivsundarR changed the title Port changes from KAFKA-18645 to share-consumers KAFKA-19062: Port changes from KAFKA-18645 to share-consumers Apr 1, 2025
@AndrewJSchofield AndrewJSchofield added KIP-932 Queues for Kafka and removed triage PRs from the community labels Apr 1, 2025
Copy link
Member

@AndrewJSchofield AndrewJSchofield left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR. Just a few small comments.

* <p>
* The actual maximum wait time is bounded by the {@link ConsumerConfig#REQUEST_TIMEOUT_MS_CONFIG} setting, which
* only applies to operations performed with the broker (coordinator-related requests and
* fetch sessions). Even if a larger timeout is specified, the consumer will not wait longer than
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: "fetch session" is not a thing for a share consumer. Maybe "operations performed with the broker, such as coordinator-related requests." would suffice.

@@ -250,6 +251,7 @@ private enum AcknowledgementMode {
this.log = logContext.logger(getClass());

log.debug("Initializing the Kafka share consumer");
this.requestTimeoutMs = config.getInt(ConsumerConfig.REQUEST_TIMEOUT_MS_CONFIG);
this.defaultApiTimeoutMs = config.getInt(ConsumerConfig.DEFAULT_API_TIMEOUT_MS_CONFIG);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that requestTimeoutMs and defaultApiTimeoutMs ought to have the same data type. Please choose the best one and make them the same, which I have a feeling would be int.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, yeah makes sense. I have updated it to int. Thanks.

Copy link
Contributor

@frankvicky frankvicky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ShivsundarR : Thanks for the patch.
LGTM

@AndrewJSchofield AndrewJSchofield merged commit ed77397 into apache:trunk Apr 1, 2025
23 of 24 checks passed
janchilling pushed a commit to janchilling/kafka that referenced this pull request Apr 4, 2025
…#19335)

Limits waiting when closing a share consumer to request.timeout.ms.

Reviewers: Andrew Schofield <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants