Skip to content

Fix #1985: fix consumer deadlock when heartbeat thread request timeout #2064

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

Merged
merged 1 commit into from
Sep 7, 2020

Conversation

huangcuiyang
Copy link
Contributor

@huangcuiyang huangcuiyang commented Jun 9, 2020

see issue: #1985


This change is Reviewable

@dpkp
Copy link
Owner

dpkp commented Jun 9, 2020

This approach is different from the 2 that I suggested in the ticket. Can you write up why you think this is the best approach?

@huangcuiyang
Copy link
Contributor Author

huangcuiyang commented Jun 9, 2020

I also think that the repair method you suggested is more thorough and better, and my method is relatively simple, in order to quickly repair production problems.

My idea for repair is thread always first get client._lock, then get coordinator._lock. When the heartbeat thread uses 2 keys to call client.poll to read data, the performance of the main consumer thread is less affected. I have tested the performance.

I hope you can use a better way to solve the design problem of multi-threaded shared client.poll

@mjattiot
Copy link

mjattiot commented Sep 9, 2020

quick question @dpkp : do you plan anytime soon a 2.0.2 release that could include this PR ?

@vsrini-ns
Copy link

Is there any plan to cut a release soon with this patch included?

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