Kafka

Hi Patrick, I've added you to the contributors group. You should now be able to self-assign the ticket. -Bill On Mon, Jun 1, 2026 at 11:17 AM Patrick Alllen <patrick.dt.allen@gmail.com> wrote: > Hi, > > My name is Patrick Allen, I am a software engineer at Palantir Technologies > on the Kafka team. I signed up to JIRA (username patrickallen) so I could > create a bug ticket, I would like to assign myself to it as I have a fix > (also would like to contribute more so useful to be able to pick up work). > > Can I be added to the developers list? > > Thanks, > > Patrick >

Hi, My name is Patrick Allen, I am a software engineer at Palantir Technologies on the Kafka team. I signed up to JIRA (username patrickallen) so I could create a bug ticket, I would like to assign myself to it as I have a fix (also would like to contribute more so useful to be able to pick up work). Can I be added to the developers list? Thanks, Patrick

In a personal cluster I used to have three kraft controllers, using Kafka 4.2.0. Because of "reasons" (the cluster is a lab), I downsized the cluster and now I only use a controller, just modifying "controller.quorum.voters" to include only the surviving controller. Working fine so far. Yes, I know that a single controller is a risk. Today I upgraded the brokers and the controller to Kafka 4.3.0 and I tried to upgrade de cluster version using "kafka-features.sh upgrade --release-version 4.3", but it is complaining that "old" controllers, offline and destroyed, are not compatible (they were Kafka 4.2.0 at the time of decommission). 1. How can I get rid of those dead controllers still haunting me? 2. I have tried to migrate to dynamic controller membership, but just changing "controller.quorum.voters" to "controller.quorum.bootstrap.server" doesn't work, although it is documented in <h...

This vote passes with 5 +1 votes (3 bindings) and no 0 or -1 votes. +1 votes PMC Members: * Mickael Maison * Lucas Brutschy * Chia-Ping Tsai Committers: * No votes Community: * Jakub Scholz * Maroš Orsák 0 votes * No votes -1 votes * No votes Vote thread: https://lists.apache.org/thread/o3rcbdwv2sl264x71yy26tv71s1mxmkv, https://lists.apache.org/thread/y5m2p9572sv7x2odc8b4yqzk7yr1z786 I'll continue with the release process and the release announcement will follow in the next few days. PoAn

Hi all, We're upgrading a Kafka Streams service from 3.9.0 to 4.x and ran into a behavioral change in REPLACE_THREAD recovery that we'd like to understand whether it's intended. Summary When the StreamsUncaughtExceptionHandler returns REPLACE_THREAD, recovery time jumps from sub-second (3.9.x) to ~`session.timeout.ms(45 s default) starting with4.0. We've traced this to the dying consumer no longer sending a LeaveGroup` request on shutdown — the broker therefore has to wait for the session to expire before it triggers a rebalance. This appears to be the combined effect of KIP-1092 (which added the GroupMembershipOperation filter in AbstractCoordinator) and Streams' replaceStreamThread() passing REMAIN_IN_GROUP to the consumer's close path. We understand the rationale (avoid partition bouncing for stateful apps where the new thread starts in the same JVM), but the 45 s floor undermines KIP-671's promise of "fast in-place recovery from ...

Hi all, We're upgrading a Kafka Streams service from 3.9.0 to 4.x and ran into a behavioral change in REPLACE_THREAD recovery that we'd like to understand whether it's intended. Summary When the StreamsUncaughtExceptionHandler returns REPLACE_THREAD, recovery time jumps from sub-second (3.9.x) to ~`session.timeout.ms(45 s default) starting with4.0. We've traced this to the dying consumer no longer sending a LeaveGroup` request on shutdown — the broker therefore has to wait for the session to expire before it triggers a rebalance. This appears to be the combined effect of KIP-1092 (which added the GroupMembershipOperation filter in AbstractCoordinator) and Streams' replaceStreamThread() passing REMAIN_IN_GROUP to the consumer's close path. We understand the rationale (avoid partition bouncing for stateful apps where the new thread starts in the same JVM), but the 45 s floor undermines KIP-671's promise of "fast in-place recovery from ...

Hi, Besides manual checks, I have also run the Strimzi test container tests on Aarch64 image build from https://dist.apache.org/repos/dist/dev/kafka/4.2.1-rc5/kafka_2.13-4.2.1.tgz, all tests passed without issues. +1 (non-binding), Cheers, Maros št 28. 5. 2026 o 6:05 Chia-Ping Tsai <chia7712@apache.org> napísal(a): > +1 (binding) > > - Run E2E tests locally; all passed with a few retries. > - Set up a 3-node cluster and ran a simple producer/consumer workflow; no > obvious performance regression. > - Run unit/integration tests locally; all passed with minimal retries. > > Best, > Chia-Ping > > On 2026/05/14 10:41:11 PoAn Yang wrote: > > Hello Kafka users, developers and client-developers, > > > > This is the third candidate for release of Apache Kafka 4.2.1. > > > > This is the first bug fix release for Apache Kafka 4.2 with fixes as > > described in the release notes. In the t...