[KAFKA-5586] Handle client disconnects during JoinGroup

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Component/s: consumer
• Assignee: Unassigned
• Reporter: Jason Gustafson
• Created: 12/Jul/17 23:08
• Updated: 29/Mar/19 23:42

Description

If a consumer disconnects with a JoinGroup in-flight, we do not remove it from the group until after the Join phase completes. If the client immediately re-sends the JoinGroup request and it already had a memberId, then the callback will be replaced and there is no harm done. For the other cases:

1. If the client disconnected due to a failure and does not re-send the JoinGroup, the consumer will still be included in the new group generation after the rebalance completes, but will immediately timeout and trigger a new rebalance.
2. If the consumer was not a member of the group and re-sends JoinGroup, then a new memberId will be created for that consumer and the old one will not be removed. When the rebalance completes, the old memberId will timeout and a rebalance will be triggered.

To address these issues, we should add some additional logic to handle client disconnections during the join phase. For newly generated memberIds, we should simply remove them. For existing members, we should probably leave them in the group and reset the heartbeat expiration task.

Note that we currently have no facility to expose disconnects from the network layer to the other layers, so we need to find a good approach for this.

Issue Links

• relates to: KAFKA-6479 Broker file descriptor leak after consumer request timeout