[
https://issues.apache.org/jira/browse/KAFKA-17403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lianet Magrans updated KAFKA-17403:
-----------------------------------
Description:
When closing a consumer, we call:
# releaseAssignmentAndLeaveGroup, which ends up updating the state machine to
LEAVING. This will make that, on the next call to HeartbeatRequestManager.poll,
a request to leave will be generated and added to the network layer.
# close the network thread (applicationEventHandler.close). This will make
sure it sends all unsent request that have been already added to the network
thread
If the releaseAssignmentAndLeaveGroup times out (most common case would be
close(0)), the flow moves into step 2, which will stop polling all managers. If
we make it to that point
([https://github.com/apache/kafka/blob/61a661ec5e627217e8b4e4c009d65ee0e0e938ba/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java#L281])
from the app thread, before the background thread has the chance to poll the
HB manager LEAVING, the request to leave will never be added to the network
layer to be sent.
Seems to me that we should ensure that the HBmanager implements the pollOnClose
and sends the leave request if the state == LEAVING. This pollOnClose is always
called when closing the managers.
was:
When closing a consumer, we call:
# releaseAssignmentAndLeaveGroup, which ends up updating the state machine to
LEAVING. This will make that, on the next call to HeartbeatRequestManager.poll,
a request to leave will be generated and added to the network layer.
# close the network client, which will send all unsent requests (
applicationEventHandler.close)
If the releaseAssignmentAndLeaveGroup times out (most common case would be
close(0)), the flow moves into step 2, which will stop polling all managers. If
we make it to that point
(https://github.com/apache/kafka/blob/61a661ec5e627217e8b4e4c009d65ee0e0e938ba/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java#L281)
from the app thread, before the background thread has the chance to poll the
HB manager LEAVING, the request to leave will never be added to the network
layer to be sent.
Seems to me that we should ensure that the HBmanager implements the pollOnClose
and sends the leave request if the state == LEAVING. This pollOnClose is always
called when closing the managers.
> New consumer may not send leave group on race condition on network thread run
> & close
> -------------------------------------------------------------------------------------
>
> Key: KAFKA-17403
> URL: https://issues.apache.org/jira/browse/KAFKA-17403
> Project: Kafka
> Issue Type: Bug
> Components: clients, consumer
> Reporter: Lianet Magrans
> Assignee: Lianet Magrans
> Priority: Major
> Labels: kip-848-client-support
>
> When closing a consumer, we call:
> # releaseAssignmentAndLeaveGroup, which ends up updating the state machine
> to LEAVING. This will make that, on the next call to
> HeartbeatRequestManager.poll, a request to leave will be generated and added
> to the network layer.
> # close the network thread (applicationEventHandler.close). This will make
> sure it sends all unsent request that have been already added to the network
> thread
> If the releaseAssignmentAndLeaveGroup times out (most common case would be
> close(0)), the flow moves into step 2, which will stop polling all managers.
> If we make it to that point
> ([https://github.com/apache/kafka/blob/61a661ec5e627217e8b4e4c009d65ee0e0e938ba/clients/src/main/java/org/apache/kafka/clients/consumer/internals/ConsumerNetworkThread.java#L281])
> from the app thread, before the background thread has the chance to poll the
> HB manager LEAVING, the request to leave will never be added to the network
> layer to be sent.
> Seems to me that we should ensure that the HBmanager implements the
> pollOnClose and sends the leave request if the state == LEAVING. This
> pollOnClose is always called when closing the managers.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
