[
https://issues.apache.org/jira/browse/KAFKA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13241442#comment-13241442
]
Prashanth Menon commented on KAFKA-301:
---------------------------------------
A suggesstion I'd like to throw out there: Can we move the core replica logic
(leaderElection, becomeLeader and becomeFollower) to where replicas are
actually managed, mainly ReplicaManager? I think this will keep things cleaner
and concise. If we do this, we should extract kafka-specific ZK logic out of
ZkUtils into KafkaZooKeeper such as functions to read the ISR, AR and leader
replica or register leader change listeners. With this, ReplicaManager becomes
the central place to manage replicas; it uses KafkaZooKeeper to interact with
ZK in a kafka-specific way and uses LogManager to create local replicas.
KafkaApis, StateRequestHandler and all the topic/leader/partition reassignment
listeners use ReplicaManager to manage replicas in a general fashion.
Thoughts?
> Implement the broker startup procedure
> --------------------------------------
>
> Key: KAFKA-301
> URL: https://issues.apache.org/jira/browse/KAFKA-301
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Attachments: kafka-301-draft.patch
>
>
> This JIRA will involve implementing the list of actions to be taken on broker
> startup, as listed by the brokerStartup() and startReplica() algorithm in the
> Kafka replication design doc. Since the stateChangeListener is part of
> KAFKA-44, this JIRA can leave it as a stub.
--
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
