You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@kafka.apache.org by "Boyang Chen (JIRA)" <ji...@apache.org> on 2019/05/19 05:53:00 UTC
[jira] [Resolved] (KAFKA-8225) Handle conflicting static member id
[ https://issues.apache.org/jira/browse/KAFKA-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boyang Chen resolved KAFKA-8225.
--------------------------------
Resolution: Fixed
> Handle conflicting static member id
> -----------------------------------
>
> Key: KAFKA-8225
> URL: https://issues.apache.org/jira/browse/KAFKA-8225
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Boyang Chen
> Assignee: Boyang Chen
> Priority: Major
>
> We need an important fix for handling the user mis-configuration for duplicate group.instance.ids. Several approaches we have discussed so far:
> # Limit resetGeneration() call to only JoinGroupResponseHandler
> # Include InstanceId in the Heartbeat and OffsetCommit APIs. Then the coordinator can return the proper error code.
> # We can can use a convention to embed the instanceId into the generated memberId. At the moment, the current format is {{{clientId}-\{random uuid}}}. For static members, I think instanceId is more useful than clientId and we could probably use timestamp as a more concise alternative to uuid. So we could have {{{instanceId}-\{timestamp}}} as the memberId for static members. Then we would be able to extract this from any request and the coordinator could use the proper error code
> Right now we are more inclined to option 2 or 3, however it requires non-trivial amount of code changes including protocol changes and fatal error handling on client side.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)