[
https://issues.apache.org/jira/browse/KAFKA-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao updated KAFKA-339:
--------------------------
Attachment: kafka-339_v2.patch
Thanks for the review. Attaching patch v2.
AbstractFetcher:
- currentOffset actually can be none. A fetcher can be removed after the
multi-fetch request is made.
AbstractFetcherManager:
-- addFetcher actually always adds a fetcher, but not always creates a new
fetcher thread. I see the naming is a bit confusing. Renamed AbstractFetcher to
AbstractFetcherThread.
-- Fetchermanager is maintaining 1 or more fetcherThreads per source broker. Be
default, there is 1 fetcherThread per broker. However, for higher degree of
parallelism, more fetcherThreads can be configured. A fetcher corresponds to
the fetching from 1 partition of a topic. Multiple fetchers can be added to a
fetcherThread.
ReplicaManager:
-- We need to get the host/port from ZK for a given broker id. Such information
should be cached. Will create a separate jira to address this issue.
The rest of of comments have been fixed.
> using MultiFetch in the follower
> --------------------------------
>
> Key: KAFKA-339
> URL: https://issues.apache.org/jira/browse/KAFKA-339
> Project: Kafka
> Issue Type: Sub-task
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Jun Rao
> Fix For: 0.8
>
> Attachments: kafka-339_v1.patch, kafka-339_v2.patch
>
> Original Estimate: 252h
> Remaining Estimate: 252h
>
> A broker could be following multiple topic/partitions from the broker.
> Instead of using 1 fetcher thread per topic/partition, it would be more
> efficient to use 1 fetcher thread that issues multi-fetch requests.
--
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
