[ https://issues.apache.org/jira/browse/KAFKA-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399838#comment-13399838 ]
Jun Rao commented on KAFKA-338: ------------------------------- Prashanth, Thanks for signing up for this jira. One thing that I realized is that it may be a bit hard to do this jira and kafka-343 (moving leader election logic to controller) independently. This is because (1) a failed broker could embed a controller and therefore it's bit hard to separate out the testing of broker failure and controller failure; (2) some of the logic in controller failover can be shared with the leader election logic in controller. Since Yang already started working on kafka-343, it's probably better if he takes on this jira as well. Do you think that you could pick up one of the following jiras instead? Sorry about that. KAFKA-330: Delete topic support KAFKA-369: remove ZK dependency on producer KAFKA-288: rework java producer API KAFKA-289: reuse TopicData when sending produce request KAFKA-355: Move the highwatermark maintenance logic out of Log. KAFKA-356: create a generic thread class > controller failover > ------------------- > > Key: KAFKA-338 > URL: https://issues.apache.org/jira/browse/KAFKA-338 > Project: Kafka > Issue Type: Sub-task > Components: core > Affects Versions: 0.8 > Reporter: Jun Rao > Assignee: Prashanth Menon > Fix For: 0.8 > > Original Estimate: 336h > Remaining Estimate: 336h > > We want to implement that controller failover logic according to > https://cwiki.apache.org/confluence/display/KAFKA/kafka+Detailed+Replication+Design+V3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira