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

Use dedicated connection for group coordinator #1822

Merged
merged 2 commits into from
Jun 19, 2019

Conversation

dpkp
Copy link
Owner

@dpkp dpkp commented May 29, 2019

This changes the coordinator_id to be a unique string, e.g., coordinator-1, so that it will get a dedicated connection. This won't eliminate lock contention because the client lock applies to all connections, but it should improve in-flight-request contention.


This change is Reviewable

@dpkp dpkp requested review from jeffwidman and tvoinarovskyi May 29, 2019 06:32
Copy link
Collaborator

@jeffwidman jeffwidman left a comment

Choose a reason for hiding this comment

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

it's late enough that I want to wait til the morning to think through this one...

kafka/cluster.py Outdated

node_id = response.coordinator_id
# Use a coordinator-specific node id so that group requuests
Copy link
Collaborator

Choose a reason for hiding this comment

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

typo: requuests

Copy link
Owner Author

Choose a reason for hiding this comment

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

uu are the best

Copy link
Collaborator

@jeffwidman jeffwidman left a comment

Choose a reason for hiding this comment

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

This looks good and makes sense

@jeffwidman jeffwidman merged commit 91f4642 into master Jun 19, 2019
@jeffwidman jeffwidman deleted the separate_coordinator_conn branch June 19, 2019 20:42
jeffwidman added a commit that referenced this pull request Jul 31, 2019
This splits the FindGroupCoordinator function (which is blocking) into
request generation / response parsing methods.

The public API does not change. However, this allows power users who are
willing to deal with risk of private methods changing under their feet
to decouple generating the message futures from processing their
responses. In other words, you can use these to fire a bunch of requests
at once and delay processing the responses until all requests are fired.

This is modeled on the work done in #1845.

Additionally, I removed the code that tried to leverage the error
checking from `cluster.add_group_coordinator()`. That code had changed
in #1822, removing most of the error checking... so it no longer adds
any value, but instead merely increases complexity and coupling.
jeffwidman added a commit that referenced this pull request Jul 31, 2019
This splits the `_find_coordinator_id()` method (which is blocking) into
request generation / response parsing methods.

The public API does not change. However, this allows power users who are
willing to deal with risk of private methods changing under their feet
to decouple generating the message futures from processing their
responses. In other words, you can use these to fire a bunch of requests
at once and delay processing the responses until all requests are fired.

This is modeled on the work done in #1845.

Additionally, I removed the code that tried to leverage the error
checking from `cluster.add_group_coordinator()`. That code had changed
in #1822, removing most of the error checking... so it no longer adds
any value, but instead merely increases complexity and coupling.
jeffwidman added a commit that referenced this pull request Jul 31, 2019
This splits the `_find_coordinator_id()` method (which is blocking) into
request generation / response parsing methods.

The public API does not change. However, this allows power users who are
willing to deal with risk of private methods changing under their feet
to decouple generating the message futures from processing their
responses. In other words, you can use these to fire a bunch of requests
at once and delay processing the responses until all requests are fired.

This is modeled on the work done in #1845.

Additionally, I removed the code that tried to leverage the error
checking from `cluster.add_group_coordinator()`. That code had changed
in #1822, removing most of the error checking... so it no longer adds
any value, but instead merely increases complexity and coupling.
jeffwidman added a commit that referenced this pull request Jul 31, 2019
This splits the `_find_coordinator_id()` method (which is blocking) into
request generation / response parsing methods.

The public API does not change. However, this allows power users who are
willing to deal with risk of private methods changing under their feet
to decouple generating the message futures from processing their
responses. In other words, you can use these to fire a bunch of requests
at once and delay processing the responses until all requests are fired.

This is modeled on the work done in #1845.

Additionally, I removed the code that tried to leverage the error
checking from `cluster.add_group_coordinator()`. That code had changed
in #1822, removing most of the error checking... so it no longer adds
any value, but instead merely increases complexity and coupling.
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.

2 participants