aiquestion commented on PR #12348: URL: https://github.com/apache/kafka/pull/12348#issuecomment-1186549702
@dajac sorry for the delay. We don't have synchronization barrier for syncGroup, but we do have a synchronization barrier for joinGroup. So if a consumer's syncGroup get 'REBALNCE_IN_PROGRESS' it should have successfully do joinGroup, so it will only missed 1 round of assignment if leader have syncGroup or will not missed any assignment if another round begin before leader do syncGroup. (If it didn't joinGroup successfully, a 'UNKNOW_MEMBER_ID' will get in syncGroup) So i think returning assignment along with 'REBALNCE_IN_PROGRESS' can be a fix for it. But as @guozhangwang said in [KAFKA-14016](https://issues.apache.org/jira/browse/KAFKA-14016), this will need broker upgrade. Since you are refactoring the rebalance protocol, a client side change that can workaround it maybe a good choice for this. i think we can just update the assignment's generation if consumer get a 'REBALNCE_IN_PROGRESS' error in syncGroup. * no partition will be dup assigned because the assignment in this consumer will not be assign to other before it revoked. And our code is just to make the revoke didn't work. * In normal cases only the Consumer which need to revoke partition will trigger a re-join, the total partitions need to be revoked is decreasing and will finally get to a Stable. WDYT? -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
