Skip to content

MINOR: Add upgrade notes for new consumer poll#5084

Merged
hachikuji merged 6 commits intoapache:trunkfrom
hachikuji:minor-kip-266-followup
May 31, 2018
Merged

MINOR: Add upgrade notes for new consumer poll#5084
hachikuji merged 6 commits intoapache:trunkfrom
hachikuji:minor-kip-266-followup

Conversation

@hachikuji
Copy link
Copy Markdown
Contributor

Added upgrade notes for the new poll() API. I also added a few small cleanups from #4855.

Committer Checklist (excluded from commit message)

  • Verify design and implementation
  • Verify test coverage and CI build status
  • Verify documentation (including upgrade notes)

@hachikuji
Copy link
Copy Markdown
Contributor Author

cc @vvcephei

@hachikuji hachikuji force-pushed the minor-kip-266-followup branch from 617895e to 6865c50 Compare May 26, 2018 19:19
@hachikuji hachikuji requested a review from guozhangwang May 26, 2018 19:19
@ijuma
Copy link
Copy Markdown
Member

ijuma commented May 27, 2018

I added a couple of comments regarding the documentation here:

c470ff7#diff-e9c1ee46a19a8684d9d8d8a8c77f9005

Generally, it seems like the commit description is very thorough, but the documentation itself is sparse. Are we sure that some of the context in the commit description is not useful for users who have to:

  1. Choose between these two methods
  2. Understand the implications of migrating to the new method?

Copy link
Copy Markdown
Contributor

@vvcephei vvcephei left a comment

Choose a reason for hiding this comment

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

Thanks.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ah, yeah, I forgot about these.

vvcephei referenced this pull request May 29, 2018
Add the new stricter-timeout version of `poll` proposed in KIP-266.

The pre-existing variant `poll(long timeout)` would block indefinitely for metadata
updates if they were needed, then it would issue a fetch and poll for `timeout` ms 
for new records. The initial indefinite metadata block caused applications to become
stuck when the brokers became unavailable. The existence of the timeout parameter
made the indefinite block especially unintuitive.

This PR adds `poll(Duration timeout)` with the semantics:
1. iff a metadata update is needed:
    1. send (asynchronous) metadata requests
    2. poll for metadata responses (counts against timeout)
        - if no response within timeout, **return an empty collection immediately**
2. if there is fetch data available, **return it immediately**
3. if there is no fetch request in flight, send fetch requests
4. poll for fetch responses (counts against timeout)
    - if no response within timeout, **return an empty collection** (leaving async fetch request for the next poll)
    - if we get a response, **return the response**

The old method, `poll(long timeout)` is deprecated, but we do not change its semantics, so it remains:
1. iff a metadata update is needed:
    1. send (asynchronous) metadata requests
    2. poll for metadata responses *indefinitely until we get it*
2. if there is fetch data available, **return it immediately**
3. if there is no fetch request in flight, send fetch requests
4. poll for fetch responses (counts against timeout)
    - if no response within timeout, **return an empty collection** (leaving async fetch request for the next poll)
    - if we get a response, **return the response**

One notable usage is prohibited by the new `poll`: previously, you could call `poll(0)` to block for metadata updates, for example to initialize the client, supposedly without fetching records. Note, though, that this behavior is not according to any contract, and there is no guarantee that `poll(0)` won't return records the first time it's called. Therefore, it has always been unsafe to ignore the response.
@vvcephei
Copy link
Copy Markdown
Contributor

I agree with @ijuma that we could elaborate more in the JavaDoc in KafkaConsumer.

On poll(long), maybe we can extend the deprecation notice to say:

@deprecated Since 2.0. Use {@link #poll(Duration)}, which doesn't block indefinitely on metadata. See KIP-266 for more details.

On poll(Duration), we can extend the JavaDoc to say:

... Performs asynchronous metadata and fetch and awaits responses for {@code timeout} amount of time. 

I'm not sure if more detail is necessary here.

@hachikuji
Copy link
Copy Markdown
Contributor Author

hachikuji commented May 29, 2018

@ijuma @vvcephei Thanks. I added a couple notes on the blocking behavior. Let me know what you think.

Copy link
Copy Markdown
Contributor

@guozhangwang guozhangwang left a comment

Choose a reason for hiding this comment

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

Could we piggy-back the comments I had in #4855 (comment) and #4855 (comment) in this PR as well?

@guozhangwang
Copy link
Copy Markdown
Contributor

Otherwise, LGTM.

@hachikuji hachikuji force-pushed the minor-kip-266-followup branch from 91ae732 to 616f6c0 Compare May 30, 2018 06:44
@hachikuji
Copy link
Copy Markdown
Contributor Author

@guozhangwang Thanks, I modified the field names of PendingCommittedOffsetRequest as suggested. About the remainingTimeAtLeastZero functions, I'm kind of hoping that we can merge #5087, which merges the behavior of the three functions into the Timer class.

@hachikuji
Copy link
Copy Markdown
Contributor Author

@guozhangwang Hold off on merging this. I will have a few additional changes after I merge #5014.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Do you need this currentTime because ensureCoordinatorReady, ensureFreshMetadata and ensureActiveGroup are somewhat long-running?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yes, right. I think the approach in #5087 is less irritating.

@hachikuji hachikuji force-pushed the minor-kip-266-followup branch from 616f6c0 to d76f802 Compare May 30, 2018 21:42
Copy link
Copy Markdown
Contributor

@vvcephei vvcephei left a comment

Choose a reason for hiding this comment

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

Looks good to me! Thanks for this patch.

@guozhangwang
Copy link
Copy Markdown
Contributor

LGTM! thanks.

* of the offset commit
*/
@Override
public void commitSync(Duration timeout) {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Ack, will do. I've had the editor on that wiki open since this morning, but keep getting distracted.

@hachikuji hachikuji merged commit 3683d47 into apache:trunk May 31, 2018
ying-zheng pushed a commit to ying-zheng/kafka that referenced this pull request Jul 6, 2018
This patch contains a few follow-up improvements/cleanup for KIP-266:

- Add upgrade notes
- Add missing `commitSync(Duration)` API
- Improve timeout messages and fix some naming inconsistencies
- Various small cleanups

Reviewers: John Roesler <john@confluent.io>, Guozhang Wang <wangguoz@gmail.com>
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.

5 participants