Skip to content
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

KAFKA-6979: Add default.api.timeout.ms to KafkaConsumer (KIP-266) #5122

Merged
merged 6 commits into from
Jun 12, 2018

Conversation

dhruvilshah3
Copy link
Contributor

@dhruvilshah3 dhruvilshah3 commented Jun 1, 2018

Adds a configuration that specifies the default timeout for KafkaConsumer APIs that could block.

Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

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

Thanks, just one minor comment.

@@ -91,6 +91,9 @@
+ "elapses the client will resend the request if necessary or fail the request if "
+ "retries are exhausted.";

public static final String MAX_BLOCK_MS_CONFIG = "max.block.ms";
public static final String MAX_BLOCK_MS_DOC = "The configuration controls the maximum time that the consumer will block for";

Choose a reason for hiding this comment

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

This is CommonClientConfigs, so we should avoid consumer-specific documentation. The producer also has a max.block.ms config, so if we could come up with a generic way to document the behavior of both, it would make sense to write it here. Otherwise, I'd suggest documenting separately.

@hachikuji
Copy link

retest this please

1 similar comment
@hachikuji
Copy link

retest this please

Copy link
Member

@satishd satishd left a comment

Choose a reason for hiding this comment

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

Thanks @dhruvilshah3 for the PR.

Current javadoc of the updated methods in this PR need to be modified for timeout behavior like it is done in other methods in this class.

  • Change the description to cover timeout expiration along with success/error scenarios.
  • Add throws javadoc for TimeoutException

@hachikuji
Copy link

Also, can you update the upgrade notes? We mention KIP-266, but not the new configuration.

@@ -218,6 +218,10 @@
public static final String REQUEST_TIMEOUT_MS_CONFIG = CommonClientConfigs.REQUEST_TIMEOUT_MS_CONFIG;
private static final String REQUEST_TIMEOUT_MS_DOC = CommonClientConfigs.REQUEST_TIMEOUT_MS_DOC;

/** <code>max.block.ms</code> */
public static final String MAX_BLOCK_MS_CONFIG = "max.block.ms";
public static final String MAX_BLOCK_MS_DOC = "The configuration controls the maximum time that the consumer will block for";

Choose a reason for hiding this comment

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

The config name was chosen for consistency with the producer, but it is not an ideal name when considering the consumer in isolation. The consumer can block longer than this if a longer timeout is passed to any blocking API that accepts a timeout. Can we explain that this config is only used as the default timeout for operations which do not have an explicit timeout option? Similarly for the changes in the upgrade docs.

Copy link
Member

@satishd satishd left a comment

Choose a reason for hiding this comment

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

LGTM, thanks @dhruvilshah3 for addressing review comments.

Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

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

LGTM. The only question I had is whether default.timeout.ms would be a better name for this config. I'll send a message to the vote thread and see what the community thinks before merging.

@guozhangwang
Copy link
Contributor

Made a pass over the PR, the change LGTM as well besides the config name.

I'm still currently in favor of adding a new config than leveraging on request.timeout.ms for the default blocking timeout value; but if there is a stronger reason to change the plan I can be convinced.

Copy link

@hachikuji hachikuji left a comment

Choose a reason for hiding this comment

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

Thanks, had a minor nitpick, but looks good otherwise. Also, can you update the PR title?

@@ -218,6 +218,10 @@
public static final String REQUEST_TIMEOUT_MS_CONFIG = CommonClientConfigs.REQUEST_TIMEOUT_MS_CONFIG;
private static final String REQUEST_TIMEOUT_MS_DOC = CommonClientConfigs.REQUEST_TIMEOUT_MS_DOC;

/** <code>max.block.ms</code> */
public static final String DEFAULT_API_TIMEOUT_MS_CONFIG = "default.api.timeout.ms";
public static final String DEFAULT_API_TIMEOUT_MS_DOC = "Specifies the timeout (in milliseconds) for consumer APIs that could block. This configuration is used as the default timeout for all consumer operations that do not explicitly accept a <code>timeout</code> option.";

Choose a reason for hiding this comment

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

nit: instead of timeout "option," how about "parameter" or "argument"?

@dhruvilshah3 dhruvilshah3 changed the title KAFKA-6979: Add max.block.ms to KafkaConsumer KAFKA-6979: Add default.api.timeout.ms to KafkaConsumer (KIP-266) Jun 12, 2018
@hachikuji hachikuji merged commit 53ca52f into apache:trunk Jun 12, 2018
hachikuji pushed a commit that referenced this pull request Jun 13, 2018
…5122)

Adds a configuration that specifies the default timeout for KafkaConsumer APIs that could block. This was introduced in KIP-266.

Reviewers: Satish Duggana <satish.duggana@gmail.com>, Jason Gustafson <jason@confluent.io>
ying-zheng pushed a commit to ying-zheng/kafka that referenced this pull request Jul 6, 2018
…pache#5122)

Adds a configuration that specifies the default timeout for KafkaConsumer APIs that could block. This was introduced in KIP-266.

Reviewers: Satish Duggana <satish.duggana@gmail.com>, Jason Gustafson <jason@confluent.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants