[
https://issues.apache.org/jira/browse/KAFKA-21212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lucas Brutschy updated KAFKA-21212:
-----------------------------------
Fix Version/s: 4.5.0
> Removed client.rack configuration is not reflected when a Streams static
> member rejoins
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-21212
> URL: https://issues.apache.org/jira/browse/KAFKA-21212
> Project: Kafka
> Issue Type: Bug
> Reporter: sanghyeok An
> Assignee: sanghyeok An
> Priority: Minor
> Labels: group-coordinator, streams
> Fix For: 4.5.0, 4.4.1
>
>
> *Description*
> When a static member using {{group.protocol=streams}} restarts after removing
> its {{client.rack}} configuration, the coordinator retains the previous rack
> ID.
> During static member replacement, the coordinator copies the previous
> member’s metadata and then treats {{RackId=null}} in the joining request as
> unchanged. Changing the rack ID to another value works, but removing it does
> not.
> *Conditions*
> # Start a Streams application with {{group.instance.id}} and
> {{{}client.rack=rack-a{}}}.
> # Shut it down gracefully using the default close behavior.
> # Remove the {{client.rack}} configuration.
> # Restart with the same static instance ID before the session timeout
> expires.
> *Expected behavior*
> The coordinator should clear the rack ID to reflect the new client
> configuration. Since the rack has changed, the group epoch should increase
> and the assignment should be recomputed.
> For regular heartbeats, {{RackId=null}} should continue to mean unchanged.
> *Actual behavior*
> The coordinator retains the previous rack ID. Group descriptions and custom
> assignors therefore receive stale rack information, and rack removal itself
> does not trigger assignment recomputation. If another metadata change
> triggers recomputation, the stale rack information is still used.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
