Skip to content

[kafka_consumer] Cleanup group coordinator lookup #1628

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

Closed
wants to merge 1 commit into from
Closed

[kafka_consumer] Cleanup group coordinator lookup #1628

wants to merge 1 commit into from

Conversation

jeffwidman
Copy link
Contributor

You must have a known group coordinator to lookup the offsets for a
consumer group that stores its offsets in Kafka. I do not understand
why this code tries to handle unknown group coordinators by
firing requests to all the brokers as that seems like a waste of network
calls.

This only refactors the existing code to be cleaner. There is room for
additional error handling and logging. Plus potentially caching the
group coordinator value on the client's cluster metadata rather than
re-fetching it every time... instead just assume it's still the old one,
and if not catch the error and trigger a group coordinator lookup.

But that is left for a later PR, this one merely cleans up the existing
logic to make it easier to refactor later.

@jeffwidman
Copy link
Contributor Author

jeffwidman commented May 29, 2018

Note that it is late at night and I have not actually tested this code yet, so I may have fat-fingered something (which hopefully the tests catch, and if not, I'm sure I'll find tomorrow when I deploy this).

But wanted to get the PR up to give folks a headstart on reviewing, as I'm planning to do additional cleanup tomorrow that depends on this.

@ofek
Copy link
Contributor

ofek commented May 30, 2018

Hello again @jeffwidman! Could you please rebase to get our new CI config? All new-style tests run on Travis now so forks will trigger builds.

@jeffwidman
Copy link
Contributor Author

jeffwidman commented May 30, 2018

@ofek that's great news. I love gitlab, but the inability to run on forks is a killer.

Rebased. I have not had a chance to deploy this myself, but if the tests pass, this should be good to merge because it's in the hotpath.

@jeffwidman
Copy link
Contributor Author

tests are failing, and a quick look through travis reveals somewhat inscrutable logs so not an obvious fix, maybe later tonight I can dig into it further

@ofek
Copy link
Contributor

ofek commented Jun 14, 2018

Hello Jeff! Have you had a chance to work on this?

@ofek ofek added this to the 6.4 milestone Jun 14, 2018
@masci masci removed this from the 6.4 milestone Jun 25, 2018
@stale
Copy link

stale bot commented Jul 14, 2018

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

@stale stale bot added the stale label Jul 14, 2018
@jeffwidman
Copy link
Contributor Author

@ofek my apologies, I am still interested in this, but am out on paternity leave / vacation / moving much of July / August, so won't be able to get to this until Sept/Oct time frame. For now it can sit, or someone else is welcome to pick it up.

@stale stale bot removed the stale label Jul 14, 2018
@ofek
Copy link
Contributor

ofek commented Jul 26, 2018

@jeffwidman No worries, congratulations! See you in September 😄

@stale
Copy link

stale bot commented Aug 25, 2018

This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community.

@stale stale bot added the stale label Aug 25, 2018
@jeffwidman jeffwidman requested a review from a team as a code owner November 8, 2018 05:58
@stale stale bot removed the stale label Nov 8, 2018
You must have a known group coordinator to lookup the offsets for a
consumer group that stores its offsets in Kafka. I do not understand
why this code tries to handle unknown group coordinators by
firing requests to all the brokers as that seems like a waste of network
calls.

This only refactors the existing code to be cleaner. There is room for
additional error handling and logging. Plus potentially caching the
group coordinator value on the client's cluster metadata rather than
re-fetching it every time... instead just assume it's still the old one,
and if not catch the error and trigger a group coordinator lookup.

But that is left for a later PR, this one merely cleans up the existing
logic to make it easier to refactor later.
@jeffwidman
Copy link
Contributor Author

Closing in favor of #2730 as that takes care of cleaning up the group coordinator lookup by relying on some other code from dpkp/kafka-python#1641

@jeffwidman jeffwidman closed this Dec 12, 2018
@jeffwidman jeffwidman deleted the cleanup-group-coordinator-lookup branch December 12, 2018 12:36
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.

3 participants