[
https://issues.apache.org/jira/browse/KAFKA-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13235707#comment-13235707
]
Jun Rao commented on KAFKA-307:
-------------------------------
Overall looks good. Some suggestions:
1. KafkaServer:
Replicas are important data structures on each broker. Could we create a
separate class Replicas that manage all replicas needed on a broker? Also, I
see 2 different apis for adding a replica data structure. For replicas
physically assigned to a broker, they always need a local Log. So, when adding
those replicas, we need an api that creates a new log, if it's not there
already (e.g. for newly created topics). The rest of replica data structures
needed on a broker are not physically assigned to this broker and they are used
to track the progress of the replicas in the followers. When adding those
replicas, we need another api that doesn't force the creation of a local log.
2. log4j.properties: Do we really want to turn off logging for all kafka during
unit tests? How about keeping it at ERROR level. We can probably turn off
logging for ZK.
> Refactor server code to remove interdependencies between LogManager and
> KafkaZooKeeper
> --------------------------------------------------------------------------------------
>
> Key: KAFKA-307
> URL: https://issues.apache.org/jira/browse/KAFKA-307
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.7, 0.8
> Reporter: Neha Narkhede
> Attachments: kafka-307-draft.patch
>
>
> Currently, LogManager wraps KafkaZooKeeper which is meant for all zookeeper
> interaction of a Kafka server. With replication, KafkaZookeeper will handle
> leader election, various state change listeners and then start replicas. Due
> to interdependency between LogManager and KafkaZookeeper, starting replicas
> is not possible until LogManager starts up completely. Due to this, we have
> to separate the broker startup procedures required for replication to get
> around this problem.
> It will be good to refactor and clean up the server code, before diving
> deeper into replication.
--
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
