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

Andrei Yu edited comment on KAFKA-13406 at 10/27/21, 2:40 PM:
--------------------------------------------------------------

[~showuon] since the possible fix is in the 
{code:java}
internals/ConsumerCoordinator
{code}
and not in publicly accessible  API of CooperativeStickyAssignor and 
AbstractStickyAssignor which we can easily pull and customly change and then 
use 
{code:java}
partition.assignment.strategy
{code} 
mapping to changed class , it's becoming a bit complicated to test on the same 
environment I did before.
Is there any chance to test changes in CooperativeStickyAssignor or 
AbstractStickyAssignor and then port them in internals ?
Or the only way for me is to test on internal classes by manually building 
snapshot from wip branch and then pointing the rest of the app use this build.



was (Author: andy_dufresne):
[~showuon] since the possible fix is in the 
{code:java}
internals/ConsumerCoordinator
{code}
and not in publicly accessible  API of CooperativeStickyAssignor and 
AbstractStickyAssignor which we can easily pull and customly change and then 
use 
{code:java}
partition.assignment.strategy
{code} 
mapping to changed class , it's becoming a bit complicated to test on the same 
environment I did before.
Is there any chance to test changes in CooperativeStickyAssignor or 
AbstractStickyAssignor and then port them in internals ?


> Cooperative sticky assignor got stuck due to assignment validation failed
> -------------------------------------------------------------------------
>
>                 Key: KAFKA-13406
>                 URL: https://issues.apache.org/jira/browse/KAFKA-13406
>             Project: Kafka
>          Issue Type: Bug
>          Components: clients
>    Affects Versions: 3.0.0
>            Reporter: Luke Chen
>            Assignee: Luke Chen
>            Priority: Major
>
> We'll do validateCooperativeAssignment for cooperative assignor, where we 
> validate if there are previously owned partitions directly transfer to other 
> consumers without "revoke" step. However, the "ownedPartition" in 
> subscription might contain out-of-dated data, which might cause the 
> validation always failure.
> We should consider the short-term fix it by disabling 
> validateCooperationAssignment for built-in cooperativeStickyAssignor because 
> we've already consider the generation in the assignor, and discard the old 
> generation ownedPartition if any.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to