[
https://issues.apache.org/jira/browse/KAFKA-21187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
sanghyeok An updated KAFKA-21187:
---------------------------------
Labels: (was: consumer group-coordinator)
> OffsetCommit returns UNKNOWN_MEMBER_ID instead of FENCED_INSTANCE_ID for
> replaced classic static members in a ConsumerGroup
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: KAFKA-21187
> URL: https://issues.apache.org/jira/browse/KAFKA-21187
> Project: Kafka
> Issue Type: Bug
> Components: consumer, group-coordinator
> Reporter: sanghyeok An
> Assignee: sanghyeok An
> Priority: Minor
>
> *Description*
> ConsumerGroup.validateOffsetCommit() looks up the member by memberId without
> first validating the current owner of groupInstanceId.
> When static member A is replaced by member B using the same instance ID, A’s
> member ID is removed. A subsequent non-transactional OffsetCommit from A
> therefore receives UNKNOWN_MEMBER_ID instead of FENCED_INSTANCE_ID.
> Under the same conditions, OffsetCommit in a ClassicGroup and classic
> Heartbeat in a ConsumerGroup return FENCED_INSTANCE_ID.
> *Impact*
> Upon receiving UNKNOWN_MEMBER_ID from OffsetCommit, the classic client clears
> its member ID and requests to rejoin. A rejoin request with an empty member
> ID and the same instance ID can replace the current static member B again.
> Heartbeat fencing does not always prevent this. If the commit error resets
> the generation first, a delayed fencing heartbeat response for the previous
> generation can be ignored as stale.
> *Expected Behavior*
> For replaced classic static members in a ConsumerGroup, OffsetCommit should
> preserve the existing static membership fencing behavior and return
> FENCED_INSTANCE_ID.
>
> *NOTE*
> {{ConsumerGroup.validateOffsetCommit()}} also handles members using the new
> consumer protocol. The new client’s commit response handler has no dedicated
> handling for {{{}FENCED_INSTANCE_ID{}}}, so any additional validation must
> consider compatibility with both protocols.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
