[
https://issues.apache.org/jira/browse/KAFKA-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13737093#comment-13737093
]
Neha Narkhede commented on KAFKA-990:
-------------------------------------
1.2 If a broker goes down after the reassignment has started, it will not enter
the ISR. So the reassignment will not complete. If the replica fails after the
2nd stage of reassignment is complete, it will get handled through the normal
logic of handling failed replicas since the reassignment is complete at that
point. I'm not sure there is any value in starting an expensive process like
reassignment of partitions when the target replicas are not even alive.
3. This is the same problem we have if we replace the broker machine and bring
up another broker with the same id. I think the problem is off somehow
throttling replica fetches. This is a good idea. Can we file a separate JIRA
for this?
> Fix ReassignPartitionCommand and improve usability
> --------------------------------------------------
>
> Key: KAFKA-990
> URL: https://issues.apache.org/jira/browse/KAFKA-990
> Project: Kafka
> Issue Type: Bug
> Reporter: Sriram Subramanian
> Assignee: Sriram Subramanian
> Attachments: KAFKA-990-v1.patch, KAFKA-990-v1-rebased.patch
>
>
> 1. The tool does not register for IsrChangeListener on controller failover.
> 2. There is a race condition where the previous listener can fire on
> controller failover and the replicas can be in ISR. Even after re-registering
> the ISR listener after failover, it will never be triggered.
> 3. The input the tool is a static list which is very hard to use. To improve
> this, as a first step the tool needs to take a list of topics and list of
> brokers to do the assignment to and then generate the reassignment plan.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
