[
https://issues.apache.org/jira/browse/KAFKA-19148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18010475#comment-18010475
]
Justin Chen edited comment on KAFKA-19148 at 7/28/25 6:26 PM:
--------------------------------------------------------------
Hi [~talasulin], thanks for the follow up.
After outputting to a file, I confirmed that messages were not lost, but
re-ordered for the case of `--producer-property acks=1`. However, across
different re-attempts with "--producer-property acks=1 --producer-property
max.in.flight.requests.per.connection=1 --producer-property retries=1000000", I
am observing messages being lost, despite reading the entire topic + outputting
to file.
With those producer configs, I expected the messages to maintain ordering and
not be dropped. Are you able to reproduce this on your end?
Sample reproduction steps/logs:
https://gist.github.com/justin-chen/27f09e73b945eb1919bb7ebf23448464
was (Author: JIRAUSER305053):
Hi [~talasulin], thanks for the follow up.
After outputting to a file, I confirmed that messages were not lost, but
re-ordered for the case of `--producer-property acks=1`. However, across
different re-attempts with `--producer-property acks=1 --producer-property
max.in.flight.requests.per.connection=1 --producer-property retries=1000000`, I
am observing messages being lost, despite reading the entire topic + outputting
to file.
With those producer configs, I expected the messages to maintain ordering and
not be dropped. Are you able to reproduce this on your end?
Sample reproduction steps/logs:
https://gist.github.com/justin-chen/27f09e73b945eb1919bb7ebf23448464
> Potential Unclean Leader Election in KRaft Despite
> unclean.leader.election.enable=false
> ---------------------------------------------------------------------------------------
>
> Key: KAFKA-19148
> URL: https://issues.apache.org/jira/browse/KAFKA-19148
> Project: Kafka
> Issue Type: Bug
> Components: controller
> Affects Versions: 3.9.0, 4.0.0
> Reporter: Julian Bergner
> Assignee: Azhar Ahmed
> Priority: Critical
> Attachments: Readme_Kraft.md, Readme_Zookeeper.md,
> docker-compose_kraft.yml, docker-compose_zookeeper.yml
>
>
> *Issue Summary:*
> We're observing unclean leader election even though
> {{{}unclean.leader.election.enable=false{}}}.
> *Scenario:*
> During a partition reassignment, if we promote a non-ISR broker to leader and
> simultaneously remove the current leader from the ISR, Kafka still elects a
> new leader from outside the ISR. This behavior contradicts the expected
> behavior when unclean leader election is explicitly disabled.
> *Details:*
> * *Original ISR:* [1, 2]
> * *New ISR after reassignment:* [3, 2]
> *Kafka Versions Tested:*
> * Kafka 4.0.0 (KRaft mode)
> * Kafka 3.9.0 (Kraft mode)
> * Kafka 3.9.0 (Zookeeper mode)
> *Observation:*
> * The behaviour differs between the two modes.
> * In Kraft, unclean leader election occurred, which should not happen with
> the config set to {{{}false{}}}.
> * In Zookeeper no unclean leader election occurred.
> *Attachments:*
> Docker Compose files and reproduction steps for both:
> * Kafka 4.0.0 (KRaft)
> * Kafka 3.9.0 (Zookeeper)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
