[
https://issues.apache.org/jira/browse/KAFKA-18164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chirag Wadhwa updated KAFKA-18164:
----------------------------------
Description:
When there are 2 share acknowledge requests to be sent to acknowledge all the
records fetched by the latest fetch and the first request was unsuccessful
because of broker shutdown, this sends back an error response to the
ShareConsumeRequestManager with a DisconnectException. This results in closing
of the shareSession on the client side. So, the next request that will be build
would have a shareSessionEpoch as 0. While this was going on, the next
shareAcknowledge request was in the process of building with the remaining
acknowledgements. But, this request cannot be successfully built, because the
shareSessionEpoch cannot be 0 for a shareAcknowledge request. Thus
{{sessionHandler.newShareAcknowledgeBuilder(groupId, fetchConfig)}} returns a
null in the {{buildRequest}} method inside ShareConsumeRequestManager. Also,
since the in memory map of acknowledgements to send is never emptied, the
subsequent polls of {{ShareConsumeRequestManager}} always tries to build a
shareAcknowledgerRequest.
Fix - empty the in memory map of acknowledgements in the case where the request
could not be built, because we do not want to send the acknowledgements again.
> Empty in memory acknowledgements when a shareAcknowledge request fails
> ----------------------------------------------------------------------
>
> Key: KAFKA-18164
> URL: https://issues.apache.org/jira/browse/KAFKA-18164
> Project: Kafka
> Issue Type: Sub-task
> Reporter: Chirag Wadhwa
> Assignee: Andrew Schofield
> Priority: Major
>
> When there are 2 share acknowledge requests to be sent to acknowledge all the
> records fetched by the latest fetch and the first request was unsuccessful
> because of broker shutdown, this sends back an error response to the
> ShareConsumeRequestManager with a DisconnectException. This results in
> closing of the shareSession on the client side. So, the next request that
> will be build would have a shareSessionEpoch as 0. While this was going on,
> the next shareAcknowledge request was in the process of building with the
> remaining acknowledgements. But, this request cannot be successfully built,
> because the shareSessionEpoch cannot be 0 for a shareAcknowledge request.
> Thus {{sessionHandler.newShareAcknowledgeBuilder(groupId, fetchConfig)}}
> returns a null in the {{buildRequest}} method inside
> ShareConsumeRequestManager. Also, since the in memory map of acknowledgements
> to send is never emptied, the subsequent polls of
> {{ShareConsumeRequestManager}} always tries to build a
> shareAcknowledgerRequest.
>
> Fix - empty the in memory map of acknowledgements in the case where the
> request could not be built, because we do not want to send the
> acknowledgements again.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
