[
https://issues.apache.org/jira/browse/KAFKA-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jun Rao updated KAFKA-362:
--------------------------
Attachment: kafka-362_v3.patch
Thanks for the review. Attach patch v3.
1a. fixed
1b. Didn't notice those configs already exist. Fixed.
2. Changed to not return a value in enqueue. Changed comments above
processPartitionData.
3. It's needed. If we shut down the fetcher thread, we could get an Interrupted
exception. In this case, we don't need to add the partitions to the list.
4. fixed.
5. It's possible to use a BlockingQueue. However, we probably still need to use
a lock to synchronize the update of partitionMap and noLeaderPartitionSet (or
queue). For example, if partitionMap is null, we don't want to update
noLeaderPartitionSet any more. This is a bit hard to guarantee just with an
atomic value since the value could change immediately after you do the check.
So keeping the current implementation for now.
> ZookeeperConsumerConnector needs to connect to new leader after leadership
> change
> ---------------------------------------------------------------------------------
>
> Key: KAFKA-362
> URL: https://issues.apache.org/jira/browse/KAFKA-362
> Project: Kafka
> Issue Type: Sub-task
> Components: core
> Affects Versions: 0.8
> Reporter: Jun Rao
> Assignee: Jun Rao
> Fix For: 0.8
>
> Attachments: kafka-362_v1.patch, kafka-362_v2.patch,
> kafka-362_v3.patch
>
> Original Estimate: 252h
> Remaining Estimate: 252h
>
> Currently, if the leader of a partition changes, the fetcher in
> ZookeeperConsumerConnector won't switch to the new leader automatically.
--
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
