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)