[
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
