mirror of https://github.com/apache/kafka.git
56a3c6dde9
CI / build (push) Waiting to run
Details
https://issues.apache.org/jira/browse/KAFKA-19485 **Bug :** There is a bug in `ShareConsumeRequestManager` where we are adding acknowledgements on initial `ShareSession` epoch even after checking for it. Added fix to only include acknowledgements in the request if we have to, PR also adds the check at another point in the code where we could potentially be sending such acknowledgements. One of the cases could be when metadata is refreshed with empty topic IDs after a broker restart. This means leader information would not be available on the node. - Consumer subscribed to a partition whose leader was node-0. - Broker restart happens and node-0 is elected leader again. Broker starts a new `ShareSession`. - Background thread sends a fetch request with **non-zero** epoch. - Broker responds with `SHARE_SESSION_NOT_FOUND`. - Client updates session epoch to 0 once it receives this error. - Client updates metadata but receives empty metadata response. (Leader unavailable) - Application thread processing the previous fetch, completes and sends acks to piggyback on next fetch. - Next fetch will send the piggyback acknowledgements on the fetch for previously subscribed partitions resulting in error from broker ("`Acknowledge data present on initial epoch`"). (Currently we attempt to send even if leader is unavailable). **Fix** : Add a check before sending out acknowledgments if we are on an initial epoch. Added unit test covering the above scenario. Reviewers: Andrew Schofield <aschofield@confluent.io> |
||
|---|---|---|
| .. | ||
| clients-integration-tests/src/test | ||
| src | ||
| .gitignore | ||