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-6326: when broker is unavailable, fast revover #4302

Open
wants to merge 2 commits into
base: trunk
Choose a base branch
from
Open

KAFKA-6326: when broker is unavailable, fast revover #4302

wants to merge 2 commits into from

Conversation

leonhong
Copy link

@leonhong leonhong commented Dec 7, 2017

  • when broker is unavailable(such as broker's machine is down), controller will wait 30 sec timeout by dedault. it seems to be that the timeout waiting is not necessary. It will be increase the MTTR of dead broker .
    _f7d1d2b4-39ae-4e02-8519-99bcba849668

@leonhong
Copy link
Author

leonhong commented Dec 7, 2017

@hachikuji @ijuma @huxihx ping...

@leonhong leonhong changed the title when broker is unavailable, fast revover KAFKA-6326: when broker is unavailable, fast revover Dec 7, 2017
@@ -76,6 +75,30 @@ public static boolean awaitReady(KafkaClient client, Node node, Time time, long
return client.isReady(node, attemptStartTime);
}

public static boolean awaitReady(KafkaClient client, Node node, Time time, long timeoutMs, Boolean fastTimeout) throws IOException {
Copy link
Contributor

Choose a reason for hiding this comment

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

why use Boolean instead of primitive ?

Copy link
Author

Choose a reason for hiding this comment

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

@tedyu Boolean 's type is reference?

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems the fastTimeout should be thread-safe since it will be accessed by both RequestSendThread and controller event thread. Perhaps volatile is a least requirement for memory visibility.

Copy link
Contributor

Choose a reason for hiding this comment

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

I changed the type to boolean here (and on line 89) - compilation passed.

This would avoid unboxing.

Copy link
Author

Choose a reason for hiding this comment

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

@huxihx @tedyu thanks for your reply. I modify the code:

  1. ensure requirement for memory visibility.
  2. weakup up the poll.
  3. fastTimeout thread safe.

@huxihx
Copy link
Contributor

huxihx commented Dec 8, 2017

In while loop, pending disconnection and aborted sends got some chances to be processed in client.poll. I am not sure if it's okay to completely skip these cleansing parts.

@leonhong
Copy link
Author

leonhong commented Dec 8, 2017

@nehanarkhede @ijuma

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