Re: [DISCUSS] KIP-1105: Make remote log manager thread-pool configs dynamic

Hi Chia-Ping, Thanks for following up on this! The `remote.log.manager.thread.pool.size` was initially planned to be deprecated as part of KIP-950 , then it was repurposed to use it as followerThreadPool in

Re: [DISCUSS] KIP-1105: Make remote log manager thread-pool configs dynamic

hi Kamal Apologies for posting on this older thread. I have a question regarding the configuration parameter remote.log.manager.thread.pool.size. Is there a Jira ticket associated with the deprecation of this setting? Additionally, is there a replacement configuration available for followerTh

Jenkins build is still unstable: Kafka » Kafka PowerPC Daily » test-powerpc #286

See

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi, Jose, Thanks for the reply. You mentioned that we still need an MV, but it's no longer in the KIP. Jun On Fri, May 2, 2025 at 12:28 PM José Armando García Sancio wrote: > Hi Jun, > > On Fri, May 2, 2025 at 1:47 PM Jun Rao wrote: > > Since we are only doing the fast HWM propagation for the

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

On Fri, May 2, 2025, at 09:54, José Armando García Sancio wrote: > Hi Colin, > > On Fri, Apr 25, 2025 at 5:42 PM Colin McCabe wrote: >> > The "initiating the downgrade" section states "It will also check that >> > the requested metadata version is compatible with all the other >> > KIP-584 feature

[jira] [Created] (KAFKA-19235) STALE_MEMBER_EPOCH is mostly non-recoverable and forces lost commits when leaving a group (KIP-848)

Travis Bischel created KAFKA-19235: -- Summary: STALE_MEMBER_EPOCH is mostly non-recoverable and forces lost commits when leaving a group (KIP-848) Key: KAFKA-19235 URL: https://issues.apache.org/jira/browse/KAFKA-

[jira] [Created] (KAFKA-19234) broker should return UNAUTHORIZATION error for non-existing topic in produce request

Jun Rao created KAFKA-19234: --- Summary: broker should return UNAUTHORIZATION error for non-existing topic in produce request Key: KAFKA-19234 URL: https://issues.apache.org/jira/browse/KAFKA-19234 Project: K

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Fri, May 2, 2025 at 1:47 PM Jun Rao wrote: > Since we are only doing the fast HWM propagation for the KRaft partition, > should we remove the changes in Replica manager where the leader will > unpark the follower fetch request if its HWM is larger than the follower? > Also, followers f

Re: [VOTE] 3.9.1 RC1

Hey folks, Thanks again for your patience! I've done the following validations: * Verified signatures * Built from source with Java 23 * Quickstarts with ZK and Kraft + minor workloads * Took a quick look at the documentation -- one thing I noticed is in the 3.9 docs, we say the latest version is

Re: [DISCUSS] KIP-1161: cleanup.policy shouldn't be empty

hi Jiunn-Yang in the "Compatibility, Deprecation, and Migration Plan", could you add description to remind readers that "clean.policy=" should be replaced by "clean.policy=none" if they do want to disable delete and compact. Best, Chia-Ping Jun Rao 於 2025年5月3日 週六 上午1:55寫道： > Hi, Jiunn-Yang, >

Re: [DISCUSS] KIP-1161: cleanup.policy shouldn't be empty

Hi, Jiunn-Yang, It's fine not to deprecate ValidList#in for now. Could you update the KIP completely? There are still references to deprecation. Thanks, Jun On Fri, May 2, 2025 at 4:59 AM 黃竣陽 wrote: > Hi Jun, > > I don’t think we should deprecate the ValidList#in method, as there may be > fut

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi, Jose, Thanks for the reply. Since we are only doing the fast HWM propagation for the KRaft partition, should we remove the changes in Replica manager where the leader will unpark the follower fetch request if its HWM is larger than the follower? Also, followers for non-KRaft partitions probab

Re: KIP-1155: Metadata Version Downgrades [DISCUSS]

Hi Colin, On Fri, Apr 25, 2025 at 5:42 PM Colin McCabe wrote: > > The "initiating the downgrade" section states "It will also check that > > the requested metadata version is compatible with all the other > > KIP-584 features that are enabled." What do you mean by this? > > So, in Kafka version 4

Re: [VOTE] 3.9.1 RC1

I will try to take a look today. Thanks folks Justine On Thu, May 1, 2025 at 7:42 PM Luke Chen wrote: > Hi all, > > So far, we've got 3 non-binding votes for v3.9.1 release. > Thanks everyone who helped validate this! > > Could PMC members (and contributors) take some time to help validate this

[VOTE] KIP-1139: Add support for OAuth jwt-bearer grant type

Hi, Thanks to all who provided feedback on KIP-1139: Add support for OAuth jwt-bearer grant type: https://cwiki.apache.org/confluence/x/uIxEF I would like to call for a vote for inclusion in the Apache Kafka 4.1.0 release. If you have comments or questions please use the existing discussion th

[jira] [Created] (KAFKA-19233) Members cannot rejoin with epoch=0 for KIP-848

Travis Bischel created KAFKA-19233: -- Summary: Members cannot rejoin with epoch=0 for KIP-848 Key: KAFKA-19233 URL: https://issues.apache.org/jira/browse/KAFKA-19233 Project: Kafka Issue Type

[VOTE] KIP-1166: Improve high-watermark replication

Hi all, Thanks for the discussion. I would like to start the voting thread for KIP-1166: Improve high-watermark replication. If you have additional comments or questions please use the discussion thread. KIP: https://cwiki.apache.org/confluence/x/uIkEFQ Discussion thread: https://lists.apache.org

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi David, On Fri, May 2, 2025 at 11:07 AM David Arthur wrote: > DA5: Do we have a way to quantify the metadata propagation latency? In the > past, I think we have eye-balled the metadata LEO between brokers and the > active controller to approximate the lag, but maybe you've found a better > way?

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

José, thanks for the updates. I think most of my questions have been answered. I had just two more: DA5: Do we have a way to quantify the metadata propagation latency? In the past, I think we have eye-balled the metadata LEO between brokers and the active controller to approximate the lag, but may

Re: [DISCUSS] KIP-1166: Improve high-watermark replication

Hi Jun, On Thu, May 1, 2025 at 12:38 PM Jun Rao wrote: > We could probably just keep the new HighWatermark field as described in the > KIP, but limit it only for KRaft. Also, since HighWatermark is a tagged > field, it probably doesn't need to be gated by an MV. Yes. Because the HighWatermark fi

RE: [DISCUSS] KIP-1174: Expose addReadOnlyStateStore in DSL (StreamsBuilder)

Hello all, Here is the link to the PR that is implemented according to the KIP, please review it for any feedback: https://github.com/apache/kafka/pull/19621 Thank you. Kind regards, Siddhatha On 2025/04/28 17:32:36 Siddhartha Devineni wrote: > Hello Kafka Community, > > I would like to propos

Re: [DISCUSS] KIP-1161: cleanup.policy shouldn't be empty

Hi Jun, I don’t think we should deprecate the ValidList#in method, as there may be future scenarios where we want to allow list configs to be empty. It’s useful to have both methods: in (which allows empty lists) and inNonEmpty (which enforces non-empty lists). > Just a minor comment. It wou

Re: [DISCUSS] KIP-1140: Avoid to return null value in Map from public api of consumer

Hi chia, Jun, > It would be useful to think through the consistency with > adminClient.listOffset() While the returned map entries are never null, a value of -1 is used to indicate the absence of an offset. Given this approach, I believe we could apply a similar strategy by introducing a new

[jira] [Created] (KAFKA-19232) Handle share session limit reached error in clients

Apoorv Mittal created KAFKA-19232: - Summary: Handle share session limit reached error in clients Key: KAFKA-19232 URL: https://issues.apache.org/jira/browse/KAFKA-19232 Project: Kafka Issue T

[jira] [Resolved] (KAFKA-19172) Handle the evictions metric in ShareSessionCache

[ https://issues.apache.org/jira/browse/KAFKA-19172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apoorv Mittal resolved KAFKA-19172. --- Resolution: Won't Fix Change is not required as we still stick with existing metric. > Hand

[jira] [Created] (KAFKA-19231) Handle fetch request when share session cache is full

Chirag Wadhwa created KAFKA-19231: - Summary: Handle fetch request when share session cache is full Key: KAFKA-19231 URL: https://issues.apache.org/jira/browse/KAFKA-19231 Project: Kafka Issue

[jira] [Resolved] (KAFKA-17942) Fix testAcknowledgementCommitCallbackInvalidRecordStateException

[ https://issues.apache.org/jira/browse/KAFKA-17942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apoorv Mittal resolved KAFKA-17942. --- Resolution: Cannot Reproduce > Fix testAcknowledgementCommitCallbackInvalidRecordStateExcept