[
https://issues.apache.org/jira/browse/KAFKA-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13276873#comment-13276873
]
Jay Kreps commented on KAFKA-336:
---------------------------------
Awesome. Couple of thoughts:
1. It would be good to seperate the tests into a serialization test that just
serializes the request and deserializes it and a seperate test that actually
sends to the server. We have found having the simple in-process test helpful
since it is easier to debug.
2. Ideally we should also add a compatability test that saves out some binary
data to ensure we don't break compatability in the future by accident. Neha has
details on this. We could wait and do this later when we have everything
working in case we need to make changes.
3. Broker is spelled as Borker
4. Can you change HashMap[Tuple2[String, Int] in the method signature to
Map[(String,Int)], means the same but is a little better style.
I recommend we not create another SimpleConsumer wrapper, but instead make a
base KafkaConnection that takes any API object, and use that to implement all
the clients. These internal things then won't need a special wrapper they can
just directly use the KafkaConnection. This also means that in the future if
the consumer needs to send a produce request (either for offset storage or
audit trail) it doesn't need a separate tcp connection.
One meta comment: these precisely versioned, compact, typed request objects are
okay for public service apis because we should make them so rarely and the
really important thing is compatability and efficiency. For these internal
broker-to-broker apis should we instead just create a generic
BrokerCommandRequest/Response which just holds a JSON string? This might be
easier to evolve. I think scala has some (fairly junky) json parser included.
This might be easier to evolve. Or maybe having this inconsistency is not worth
it. It really depends on how many of these we think we will have.
> add an admin RPC to communicate state changes between the controller and the
> broker
> -----------------------------------------------------------------------------------
>
> Key: KAFKA-336
> URL: https://issues.apache.org/jira/browse/KAFKA-336
> Project: Kafka
> Issue Type: Sub-task
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Yang Ye
> Fix For: 0.8
>
> Attachments: controller_broker_RPC.patch
>
> Original Estimate: 252h
> Remaining Estimate: 252h
>
> Based on the discussion in
> https://cwiki.apache.org/confluence/display/KAFKA/kafka+Detailed+Replication+Design+V3
> , it's more efficient to communicate state change commands between the
> controller and the broker using a direct RPC than via ZK. This ticket will be
> implementing an admin RPC client for the controller to send state change
> commands.
--
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
