[
https://issues.apache.org/jira/browse/KAFKA-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15347486#comment-15347486
]
Jason Gustafson commented on KAFKA-3834:
----------------------------------------
[~ewencp] Depends on the nature of the problem, I guess. We usually treat
coordinator unavailability as a transient problem which will eventually
recover. For example, when an offsets partition is being migrated to another
broker, there is a short window where we won't be able to determine which
broker is the coordinator. In these cases, I think it makes more sense to
retry. However, if we cannot communicate with any broker (that is, we can't
fetch topic metadata), then raising an exception may be preferable. This latter
case has been discussed before and I'm not attempting a solution here. My
suggestion is to keep the current behavior, but not block poll.
> Consumer should not block in poll on coordinator discovery
> ----------------------------------------------------------
>
> Key: KAFKA-3834
> URL: https://issues.apache.org/jira/browse/KAFKA-3834
> Project: Kafka
> Issue Type: Improvement
> Components: consumer
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
>
> Currently we block indefinitely in poll() when discovering the coordinator
> for the group. Instead, we can return an empty record set when the passed
> timeout expires. The downside is that it may obscure the underlying problem
> (which is usually misconfiguration), but users typically have to look at the
> logs to figure out the problem anyway.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
