[
https://issues.apache.org/jira/browse/KAFKA-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15843389#comment-15843389
]
Jason Gustafson commented on KAFKA-4704:
----------------------------------------
[~onurkaraman] Interesting point. Unfortunately, this patch won't fix that
problem. The only thing I can think of would be to skip the generation check
when the group is empty. Seems a little dangerous, but possibly justifiable. I
suggest we address this as part of the consumer migration work itself.
> Group coordinator cache loading fails if groupId is used first for consumer
> groups and then for simple consumer
> ---------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-4704
> URL: https://issues.apache.org/jira/browse/KAFKA-4704
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.10.0.0, 0.10.0.1, 0.10.1.0, 0.10.1.1
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
> Fix For: 0.10.2.0
>
>
> When all the members in a consumer group have died and all of its offsets
> have expired, we write a tombstone to __consumer_offsets so that its group
> metadata is cleaned up. It is possible that after this happens, the same
> groupId is then used only for offset storage (i.e. by "simple" consumers).
> Our current cache loading logic, which is triggered when a coordinator first
> takes over control of a partition, does not account for this scenario and
> would currently fail.
> This is probably an unlikely scenario to hit in practice, but it reveals the
> lack of test coverage around the cache loading logic. We should improve this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
