[
https://issues.apache.org/jira/browse/KAFKA-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14025663#comment-14025663
]
Neha Narkhede commented on KAFKA-1316:
--------------------------------------
bq. So let's really put some thought into seeing if we have these layers right
and have the right apis.
I tried writing some consumer code using these APIs. As mentioned before, my
feedback is that
1. we need a blocking version of ready/poll since the consumer's group
management protocol is blocking in nature. So there are a lot of repeated
while(..) { poll() }.
2. Independent of this, there are several config options that are repeated
between the producer and consumer.
3. Also there are some APIs that are private but really should be public
utility APIs since those are useful to producer and consumer
(NetworkClient.selectMetadataDestination).
> 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)
