[jira] [Created] (KAFKA-16232) kafka hangs forever in the starting process if the authorizer future is not returned

Luke Chen created KAFKA-16232: - Summary: kafka hangs forever in the starting process if the authorizer future is not returned Key: KAFKA-16232 URL: https://issues.apache.org/jira/browse/KAFKA-16232

Re: [DISCUSS] KIP-939: Support Participation in 2PC

Hi Artem, I am not sure what you mean by guarantee, but I am referring to a better operational experience. You mentioned this as the first benefit of an explicit "prepare" RPC in the KIP. 1. Transactions that haven’t reached “prepared” state can be aborted via timeout. However, in explaining

Re: [DISCUSS] KIP-939: Support Participation in 2PC

Hi Jun, > 20. For Flink usage, it seems that the APIs used to abort and commit a prepared txn are not symmetric. For Flink it is expected that Flink would call .commitTransaction or .abortTransaction directly, it wouldn't need to deal with PreparedTxnState, the outcome is actually determined by

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #2624

See Changes: -- [...truncated 460558 lines...] [2024-02-06T22:32:37.196Z] [2024-02-06T22:32:37.196Z] Gradle Test Run :core:test > Gradle Test Executor 94 >

[jira] [Created] (KAFKA-16231) Update consumer_test.py to support KIP-848’s group protocol config

Kirk True created KAFKA-16231: - Summary: Update consumer_test.py to support KIP-848’s group protocol config Key: KAFKA-16231 URL: https://issues.apache.org/jira/browse/KAFKA-16231 Project: Kafka

[jira] [Created] (KAFKA-16230) Update verifiable_consumer to support KIP-848’s group protocol config

Kirk True created KAFKA-16230: - Summary: Update verifiable_consumer to support KIP-848’s group protocol config Key: KAFKA-16230 URL: https://issues.apache.org/jira/browse/KAFKA-16230 Project: Kafka

Re: KRaft controller number of replicas

A 5-node quorum doesn't make a lot of sense in a setting where those nodes are also Kafka brokers. When they're ZooKeeper voters, a quorum* of 5 makes a lot of sense, because you can take an unscheduled voter failure during a rolling-reboot scheduled maintenance without significant service

[jira] [Resolved] (KAFKA-16133) Commits during reconciliation always time out

[ https://issues.apache.org/jira/browse/KAFKA-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lianet Magrans resolved KAFKA-16133. Fix Version/s: 3.7.0 (was: 3.8.0) Resolution: Fixed >

[jira] [Created] (KAFKA-16229) Slow expiration of Producer IDs leading to high CPU usage

Jorge Esteban Quilcate Otoya created KAFKA-16229: Summary: Slow expiration of Producer IDs leading to high CPU usage Key: KAFKA-16229 URL: https://issues.apache.org/jira/browse/KAFKA-16229

[jira] [Created] (KAFKA-16228) Add --remote-log-metadata-decoder to kafka-dump-log.sh

Federico Valeri created KAFKA-16228: --- Summary: Add --remote-log-metadata-decoder to kafka-dump-log.sh Key: KAFKA-16228 URL: https://issues.apache.org/jira/browse/KAFKA-16228 Project: Kafka

Re: KRaft controller number of replicas

Hi Dani, I believe the limitation that this documentation is hinting at is the motivation for KIP-996 [1], and the notice in the documentation would be removed once KIP-996 lands. You can read the KIP for a brief explanation and link to a more in-depth explanation of the failure scenario. While

Re: [DISCUSS] KIP-890 Server Side Defense

I don't think AddPartitions is a good example since we currenly don't gate the version on TV or MV. (We only set a different flag depending on the TV) Even if we did want to gate it on TV, I think the idea is to move away from MV gating inter broker protocols. Ideally we can get to a state where

Re: [VOTE] KIP-951: Leader discovery optimisations for the client

David Thanks, i have shared it here https://lists.apache.org/thread/0fd0og8j6gj9b2wtppnpy7fz8pzzv20r On Tue, Feb 6, 2024 at 4:13 PM David Jacot wrote: > Hi, > > Thanks for bringing this up. It may be worth bringing it in the 3.7 release > thread too as it may qualify as a blocker for the

Re: Apache Kafka 3.7.0 Release

Hi Folks KIP-951 was delivered fully in AK 3.7. Its 1st optimisation was delivered in 3.6.1, to skip backoff period for a produce batch being retried to new leader i.e. KAFKA-15415. KAFKA-15415 current implementation introduced a performance regression, by increasing synchronization on the

Re: [VOTE] KIP-951: Leader discovery optimisations for the client

Hi, Thanks for bringing this up. It may be worth bringing it in the 3.7 release thread too as it may qualify as a blocker for the release. Best, David On Tue, Feb 6, 2024 at 5:09 PM Mayank Shekhar Narula < mayanks.nar...@gmail.com> wrote: > Hi Folks > > KIP-951 was delivered fully in AK 3.7.

Re: [VOTE] KIP-951: Leader discovery optimisations for the client

Hi Folks KIP-951 was delivered fully in AK 3.7. Its 1st optimisation was delivered in 3.6.1, to skip backoff period for a produce batch being retried to new leader i.e. KAFKA-15415. KAFKA-15415 current implementation introduced a performance regression, by increasing synchronization on the

[jira] [Created] (KAFKA-16227) Console consumer fails with `IllegalStateException`

David Jacot created KAFKA-16227: --- Summary: Console consumer fails with `IllegalStateException` Key: KAFKA-16227 URL: https://issues.apache.org/jira/browse/KAFKA-16227 Project: Kafka Issue

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2623

See

[jira] [Created] (KAFKA-16226) Performance regression in Trogdor benchmark with high partition counts

Mayank Shekhar Narula created KAFKA-16226: - Summary: Performance regression in Trogdor benchmark with high partition counts Key: KAFKA-16226 URL: https://issues.apache.org/jira/browse/KAFKA-16226

[jira] [Resolved] (KAFKA-15970) KIP-951, port newly added tests in FetcherTest.java to FetchRequestManagerTest.ajva

[ https://issues.apache.org/jira/browse/KAFKA-15970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mayank Shekhar Narula resolved KAFKA-15970. --- Resolution: Fixed > KIP-951, port newly added tests in FetcherTest.java to

KRaft controller number of replicas

Hello, I would like to clarify a statement I found in the KRaft documentation, in the deployment section [1]: > More than 3 controllers is not recommended in critical environments. In the rare case of a partial network failure it is possible for the cluster metadata quorum to become unavailable.