[
https://issues.apache.org/jira/browse/KAFKA-902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344500#comment-14344500
]
Jay Kreps commented on KAFKA-902:
---------------------------------
This looks good to me. I'd second Grant's comments:
1. I agree we should probably make it configurable and mark the configuration
low importance. This kind of configuration is hyper-annoying because no one
will ever set it but it's probably the right thing to do.
2. We should definitely apply the same thing to the reconnect backoff as well
as metadata max age (if everyone disconnects at time X they will all expire
their metadata at X+metadata.max.age.ms so jittering that will help too).
Another thing is that this jitter is only additive, so if you configure a
backoff of 10 ms, your observed backoff time will be 15 ms. Also 10 ms will be
a bit large if you configure a 1 ms backoff and zero ends up being kind of
magical. I don't think this is really too terrible and it is simple, so maybe
we should just leave it.
Another possibility would be something like using a jitter that is a random int
in +/- min(20, 0.2 * backoff_ms).
> Randomize backoff on the clients for metadata requests
> ------------------------------------------------------
>
> Key: KAFKA-902
> URL: https://issues.apache.org/jira/browse/KAFKA-902
> Project: Kafka
> Issue Type: Bug
> Components: clients
> Affects Versions: 0.8.0
> Reporter: Neha Narkhede
> Assignee: Geoffrey Anderson
> Priority: Critical
> Labels: newbie
> Attachments: KAFKA-902.patch
>
>
> If a Kafka broker dies and there are a large number of clients talking to the
> Kafka cluster, each of the clients can end up shooting metadata requests at
> around the same time. It is better to randomize the backoff on the clients so
> the metadata requests are more evenly spread out
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
