[
https://issues.apache.org/jira/browse/KAFKA-16984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lianet Magrans updated KAFKA-16984:
-----------------------------------
Description:
When the new consumer attempts to leave a group, it sends a leave group request
in a fire-and-forget mode, so, as soon as the request is generated, it will:
1. transitions to UNSUBSCRIBED
2. complete the leaveGroup operation future
This task focus on point 2, which has the undesired side-effect that whatever
might have been waiting for the leave to do something else, will carry on, ex.
consumer close, leading to responses to disconnected clients we've seen when
running stress tests)
When leaving a group while closing a consumer, the member sends the leave
request and moves on to next operation, which is closing the network thread, so
we end up with disconnected client receiving responses from the server. We
should send leave group heartbeat, and transition to UNSUBSCRIBE, but only
complete the leave operation when we get a response for it, which is a much
more accurate confirmation that the consumer left the group and can move on
with other operations.
Note that with this task we'll only focus on changing the behaviour for the
leave operation completion (point 2 above) to tidy up the close flow. We are
not changing the transition to UNSUBSCRIBED, as it would require further
consideration: leaving the consumer in a new LEAVING_WAITING_FOR_RESPONSE kind
of state after sending the leave would require to review all the possible
interactions that could happen while on such new state
was:When the new consumer attempts to leave a group, it sends a leave group
request in a fire-and-forget mode, so it transitions to UNSUBSCRIBED as soon as
it generates the requests (without waiting for a response. Note that this
transition to unsubscribe marks the leave operation as completed. This makes
that, when leaving a group while closing a consumer, the member sends the leave
request and moves on to next operation, which is closing the network thread, so
we end up with disconnected client receiving responses from the server. We
should send leave group heartbeat, and transition to UNSUBSCRIBE (completes the
leave operation) only when we get a response for it, which is a much more
accurate confirmation that the consumer left the group and can move on with
other operations
> New consumer should not complete leave operation until it gets a response
> -------------------------------------------------------------------------
>
> Key: KAFKA-16984
> URL: https://issues.apache.org/jira/browse/KAFKA-16984
> Project: Kafka
> Issue Type: Bug
> Components: clients, consumer
> Affects Versions: 3.8.0
> Reporter: Lianet Magrans
> Assignee: Lianet Magrans
> Priority: Major
> Labels: kip-848
> Fix For: 3.9.0
>
>
> When the new consumer attempts to leave a group, it sends a leave group
> request in a fire-and-forget mode, so, as soon as the request is generated,
> it will:
> 1. transitions to UNSUBSCRIBED
> 2. complete the leaveGroup operation future
> This task focus on point 2, which has the undesired side-effect that whatever
> might have been waiting for the leave to do something else, will carry on,
> ex. consumer close, leading to responses to disconnected clients we've seen
> when running stress tests)
> When leaving a group while closing a consumer, the member sends the leave
> request and moves on to next operation, which is closing the network thread,
> so we end up with disconnected client receiving responses from the server. We
> should send leave group heartbeat, and transition to UNSUBSCRIBE, but only
> complete the leave operation when we get a response for it, which is a much
> more accurate confirmation that the consumer left the group and can move on
> with other operations.
> Note that with this task we'll only focus on changing the behaviour for the
> leave operation completion (point 2 above) to tidy up the close flow. We are
> not changing the transition to UNSUBSCRIBED, as it would require further
> consideration: leaving the consumer in a new LEAVING_WAITING_FOR_RESPONSE
> kind of state after sending the leave would require to review all the
> possible interactions that could happen while on such new state
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
