[
https://issues.apache.org/jira/browse/KAFKA-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15007059#comment-15007059
]
Jason Gustafson commented on KAFKA-2841:
----------------------------------------
[~junrao] That is correct. The problem is that the group may be loaded more
than once and the cached metadata object which holds group and member state may
be replaced. When this happens, you can get very strange behavior since
join/sync response callbacks may be lost and delayed operations (which still
refer to the original metadata object) can cause conflicts. My patch makes this
safer by preventing this replacement from taking place when a partition is
loaded and by cleaning up the group state when the cached metadata is unloaded
due to partition emigration to a new leader.
> Group metadata cache loading is not safe when reloading a partition
> -------------------------------------------------------------------
>
> Key: KAFKA-2841
> URL: https://issues.apache.org/jira/browse/KAFKA-2841
> Project: Kafka
> Issue Type: Bug
> Affects Versions: 0.9.0.0
> Reporter: Jason Gustafson
> Assignee: Jason Gustafson
> Priority: Blocker
> Fix For: 0.9.0.0
>
>
> If the coordinator receives a leaderAndIsr request which includes a higher
> leader epoch for one of the partitions that it owns, then it will reload the
> offset/metadata for that partition again. This can happen because the leader
> epoch is incremented for ISR changes which do not result in a new leader for
> the partition. Currently, the coordinator replaces cached metadata values
> blindly on reloading, which can result in weird behavior such as unexpected
> session timeouts or request timeouts while rebalancing.
> To fix this, we need to check that the group being loaded has a higher
> generation than the cached value before replacing it. Also, if we have to
> replace a cached value (which shouldn't happen except when loading), we need
> to be very careful to ensure that any active delayed operations won't affect
> the group.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
