KAFKA-16905: Fixed potential thread block by admin API#16217
KAFKA-16905: Fixed potential thread block by admin API#16217mumrah merged 2 commits intoapache:trunkfrom
Conversation
AndrewJSchofield
left a comment
There was a problem hiding this comment.
Thanks for the PR. Looks good to me.
|
there is checkstyle error |
My bad, fixed. |
|
Can you open a Jira so it's easier for users to find? Thanks |
|
lianetm
left a comment
There was a problem hiding this comment.
Thanks @apoorvmittal10, LGTM.
mumrah
left a comment
There was a problem hiding this comment.
Thanks for finding and fix this @apoorvmittal10 👍
LGTM
|
Hey guys -- just a gentle reminder to please check the builds carefully before merging. This patch seems to have introduced an issue that caused several tests to hang indefinitely, as you can see in the PR build for this which aborted after 7+ hours We already have a fix and are just waiting to confirm it fixes the issue so no harm done (I've definitely merged something that broke the build myself in the past). Just wanted to raise this since the 3.8 code freeze is fast approaching 🙂 |
Fix to complete Future which was stuck due the exception.getCause() throws an error. The fix in the #16217 unblocked blocking thread but exception in catch block from blocking get call was wrapped in ExecutionException which is not the case when moved to async workflow hence getCause is not needed. Reviewers: Luke Chen <showuon@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
…eTopics (apache#16217) Reviewers: Andrew Schofield <aschofield@confluent.io>, Lianet Magrans <lianetmr@gmail.com>, David Arthur <mumrah@gmail.com>
Fix to complete Future which was stuck due the exception.getCause() throws an error. The fix in the apache#16217 unblocked blocking thread but exception in catch block from blocking get call was wrapped in ExecutionException which is not the case when moved to async workflow hence getCause is not needed. Reviewers: Luke Chen <showuon@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
…eTopics (apache#16217) Reviewers: Andrew Schofield <aschofield@confluent.io>, Lianet Magrans <lianetmr@gmail.com>, David Arthur <mumrah@gmail.com>
Fix to complete Future which was stuck due the exception.getCause() throws an error. The fix in the apache#16217 unblocked blocking thread but exception in catch block from blocking get call was wrapped in ExecutionException which is not the case when moved to async workflow hence getCause is not needed. Reviewers: Luke Chen <showuon@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
…eTopics (apache#16217) Reviewers: Andrew Schofield <aschofield@confluent.io>, Lianet Magrans <lianetmr@gmail.com>, David Arthur <mumrah@gmail.com>
Fix to complete Future which was stuck due the exception.getCause() throws an error. The fix in the apache#16217 unblocked blocking thread but exception in catch block from blocking get call was wrapped in ExecutionException which is not the case when moved to async workflow hence getCause is not needed. Reviewers: Luke Chen <showuon@gmail.com>, Chia-Ping Tsai <chia7712@gmail.com>
The PR moves the blocking call of
describeClusterto async. Though the issue coldn't be re-produced in Kafka intgeration tests but a thread block ondescribeClusterhas been observed when using admin describeTopic API in kafka-rest integrations tests.The threads blocks indefinetly
Committer Checklist (excluded from commit message)