You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Neha Narkhede (JIRA)" <ji...@apache.org> on 2014/02/01 20:54:09 UTC

[jira] [Commented] (KAFKA-1096) An old controller coming out of long GC could update its epoch to the latest controller's epoch

    [ https://issues.apache.org/jira/browse/KAFKA-1096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13888707#comment-13888707 ] 

Neha Narkhede commented on KAFKA-1096:
--------------------------------------

This is relatively rare, moving to 0.8.2

> An old controller coming out of long GC could update its epoch to the latest controller's epoch
> -----------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-1096
>                 URL: https://issues.apache.org/jira/browse/KAFKA-1096
>             Project: Kafka
>          Issue Type: Bug
>          Components: controller
>    Affects Versions: 0.8.0
>            Reporter: Swapnil Ghike
>             Fix For: 0.8.2
>
>
> If a controller GCs for too long, we could have two controllers in the cluster. The controller epoch is supposed to minimize the damage in such a situation, as the brokers will reject the requests sent by the controller with an older epoch.
> When the old controller is still in long GC, a new controller could be elected. This will fire ControllerEpochListener on the old controller. When it comes out of GC, its ControllerEpochListener will update its own epoch to the new controller's epoch. So both controllers are now able to send out requests with the same controller epoch until the old controller's handleNewSession() can execute in the controller lock. 
> ControllerEpochListener does not seem necessary, so we can probably delete it.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)