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-10134: Still depends on existence of any fetchable partitions to block on join #9011

Conversation

guozhangwang
Copy link
Contributor

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
Contributor

@guozhangwang There is one detail I think we're missing. If updateAssignmentMetadataIfNeeded does not block, then execution will fall through to pollForFetches. I would like to understand why pollForFetches is not blocking. As far as I can tell, the only thing that would cause that is if Heartbeat.timeToNextHeartbeat is returning 0.

@guozhangwang
Copy link
Contributor Author

guozhangwang commented Jul 28, 2020

@hachikuji That's what I was wondering as well. From the logs we have: https://issues.apache.org/jira/secure/attachment/13008127/consumer5.log.2020-07-22.log

If you search for Returning timer remaining you can find that in most time it is normal, and during that re-joining it is indeed returning 0 but that's expected since we could not connect to the broker during that period of time. So there's no surprising timeToNextHeartbeat returning 0 from that run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants