[
https://issues.apache.org/jira/browse/KAFKA-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13253467#comment-13253467
]
Jay Kreps commented on KAFKA-301:
---------------------------------
Here are some superficial comments:
1. This adds more kafka-specific logic into ZkUtils as static methods. I think
Prasanth commented on this. Maybe given the current state, it is better to
ignore this for now, but I feel this is a bad approach as ZkUtils is
fundamentally unmockable, right? A better way would be to make fully
object-oriented classes that represent the domain logic we have around
partitions, clusters, epochs, etc. This is harder to do because you have to
think through this model but ultimately easier to work with and test, I feel.
It definitely makes sense to have utility methods like readData() but
application specific methods like incrementEpochForPartition() are less good.
2. "ZKQueue" should be "ZkQueue" for consistency I think.
3. StateChangeRequest is not really a request in the sense of Request.scala,
right? We are already unfortunately overloading Request twice, once for API
objects and once for the RequestQueue items. Could we call these Commands?
4. I like the ZKQueue a lot, I think that approach to wrapping up zk logic is
very good. One thing though is that the usage of this queue is a bit difficult
because as I understand the poll/drain methods are non-blocking, so one has to
write a zk watcher to trigger the action. I wonder if a better way wouldn't be
to wrap up the zk watcher logic as well so that the queue acted more like a juc
BlockingQueue. In this case the usage would be more like while(true) { val cmd
= q.take(); handle(cmd);}. In other words, I should be able to start a kafka
broker I have instantiated with a fake ZkQueue and pump in cmds to test it out
without ZK. I am not sure if this is really possible to do or if it would
actually be better, just throwing it out there...
> 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
> Labels: replication
> Attachments: kafka-301-draft.patch, kafka-301-v1.patch,
> kafka-301-v2.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
