[ 
https://issues.apache.org/jira/browse/KAFKA-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843177#comment-16843177
 ] 

ASF GitHub Bot commented on KAFKA-8225:
---------------------------------------

guozhangwang commented on pull request #6650: KAFKA-8225 & KIP-345 part-2: 
fencing static member instances with conflicting group.instance.id
URL: https://github.com/apache/kafka/pull/6650
 
 
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> 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)

Reply via email to