[
https://issues.apache.org/jira/browse/KAFKA-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063437#comment-16063437
]
Jun Rao commented on KAFKA-5473:
--------------------------------
[~prasincs], there are a couple cases to consider. (1) This is the case that
the broker knows for sure that it's not registered with ZK. In this case, it
seems failing the broker is better since from the ZK server's perspective, the
broker is down and failing the broker will make the behavior of the broker
consistent with what's in ZK server. This is the issue that this particular
jira is trying to solve. I think we can just wait up to zk.connection.time.ms
and do a clean shutdown. (2) There is another case that the broker is
partitioned off from ZK server. In this case, ZK server may have expired the
session of the broker. However, until the network connection is back, the
broker doesn't know that its session has expired. In that mode, currently the
broker doesn't shut down and just wait until the network connection is back.
> handle ZK session expiration properly when a new session can't be established
> -----------------------------------------------------------------------------
>
> Key: KAFKA-5473
> URL: https://issues.apache.org/jira/browse/KAFKA-5473
> Project: Kafka
> Issue Type: Sub-task
> Affects Versions: 0.9.0.0
> Reporter: Jun Rao
> Assignee: Prasanna Gautam
>
> In https://issues.apache.org/jira/browse/KAFKA-2405, we change the logic in
> handling ZK session expiration a bit. If a new ZK session can't be
> established after session expiration, we just log an error and continue.
> However, this can leave the broker in a bad state since it's up, but not
> registered from the controller's perspective. Replicas on this broker may
> never to be in sync.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
