[
https://issues.apache.org/jira/browse/KAFKA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025757#comment-14025757
]
Jay Kreps commented on KAFKA-1316:
----------------------------------
2. Sure. I guess I don't feel this is necessarily bad as long as the two
configs are things that change independently.
3. Yeah totally, that is what I was responding to. My concern is just that this
method is kind of insane (it returns a good node to make a metadata request to
or sometimes null and assumes you will keep trying while calling poll in
between). So maybe there is a way to refactor this into a general facility...
> 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)
