[
https://issues.apache.org/jira/browse/KAFKA-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13499873#comment-13499873
]
Neha Narkhede commented on KAFKA-532:
-------------------------------------
Thanks for reviewing patch v5 quickly !
50. True, thought about it. But in both of these cases, the error code is a
request level error code. It is saying that this *request* is coming from an
invalid controller. It is true that for other requests, there are just
partition level error codes, but I'm guessing there are error codes that make
sense at the request level as well. When you get request level errors, the
response is empty and the error code is set. The other option of dealing with
this is, if you have a request level error code, set it as every partition's
error code, and skip the request level error code. But this seemed a little
hacky since now the response map will not be empty and will contain each
partition with the same error code. So it felt like we are trying to retrofit
something to match the currently chosen response format. I can see both sides
and probably the user's convenience would help pick one option. If this
discussion already happened sometime, I can make the change right away. If not,
do you think its worthwhile to quickly check on the user list ? If so, I can
commit this patch and make that change, whatever is decided, in a follow up.
51. Not intended, will remove on commit.
> Multiple controllers can co-exist during soft failures
> ------------------------------------------------------
>
> Key: KAFKA-532
> URL: https://issues.apache.org/jira/browse/KAFKA-532
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.8
> Reporter: Neha Narkhede
> Assignee: Neha Narkhede
> Priority: Blocker
> Labels: bugs
> Attachments: kafka-532-v1.patch, kafka-532-v2.patch,
> kafka-532-v3.patch, kafka-532-v4.patch, kafka-532-v5.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> If the current controller experiences an intermittent soft failure (GC pause)
> in the middle of leader election or partition reassignment, a new controller
> might get elected and start communicating new state change decisions to the
> brokers. After recovering from the soft failure, the old controller might
> continue sending some stale state change decisions to the brokers, resulting
> in unexpected failures. We need to introduce a controller generation id that
> increments with controller election. The brokers should reject any state
> change requests by a controller with an older generation id.
--
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
