Jason Gustafson created KAFKA-12363:
---------------------------------------
Summary: Simplify static group memberId update logic
Key: KAFKA-12363
URL: https://issues.apache.org/jira/browse/KAFKA-12363
Project: Kafka
Issue Type: Improvement
Reporter: Jason Gustafson
In KAFKA-10284, we amended the JoinGroup logic to ensure that the memberId of
static members always gets persisted. The way this works is the following:
1. When the JoinGroup is received, we immediately replace the current memberId
with the updated memberId.
2. We then send an append to the log to update group metadata
3. If the append is unsuccessful, we revert to the old memberId and we return
UNKNOWN_MEMBER_ID in the response for the new member.
4. If the append is successful, we return the new memberId in the JoinGroup
response.
I am not sure if there are any correctness problems with this logic, but it
does seem strange. For example, we can end up fencing the old memberId after
step 1 even if we end up reverting in step 3. I think it would be simpler to
structure this as follows:
1. When the JoinGroup is received, send an append to the log to update group
metadata
2. If the append succeeds, replace the existing memberId with the new committed
memberId.
3. If the append fails, return UNKNOWN_MEMBER_ID to let the new member retry.
Basically we don't surface the effect of the member replacement until we know
it has been committed to the log, which avoids the weird revert logic.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
