[
https://issues.apache.org/jira/browse/KAFKA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027085#comment-14027085
]
Neha Narkhede commented on KAFKA-1316:
--------------------------------------
2. Ya, I kind of agree with you. These configs might start off identical but
might evolve independently.
3. Following up on our discussion, I think there is value in refactoring the
logic to select a node (out of all nodes) that can receive a request and it
makes sense for this logic to just return the least loaded node. In that case,
we would end up with the following APIs in NetworkClient -
selectLeastLoadedNode(Cluster), isReady(Node), makeReady(Node) and poll().
selectLeastLoadedNode() will return the least loaded node, but you may not have
a connection to that node necessarily. So the isReady() call will return false
at which point you have to invoke makeReady(), finally followed up with poll().
> Refactor Sender
> ---------------
>
> Key: KAFKA-1316
> URL: https://issues.apache.org/jira/browse/KAFKA-1316
> Project: Kafka
> Issue Type: Sub-task
> Components: producer
> Reporter: Jay Kreps
> Assignee: Jay Kreps
> Attachments: KAFKA-1316.patch, KAFKA-1316_2014-06-03_11:15:38.patch,
> KAFKA-1316_2014-06-03_14:33:33.patch, KAFKA-1316_2014-06-07_11:20:38.patch
>
>
> Currently most of the logic of the producer I/O thread is in Sender.java.
> However we will need to do a fair number of similar things in the new
> consumer. Specifically:
> - Track in-flight requests
> - Fetch metadata
> - Manage connection lifecycle
> It may be possible to refactor some of this into a helper class that can be
> shared with the consumer. This will require some detailed thought.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
