[jira] [Created] (KAFKA-17475) Change the base image of e2e from openjdk to eclipse-temurin

Chia-Ping Tsai created KAFKA-17475: -- Summary: Change the base image of e2e from openjdk to eclipse-temurin Key: KAFKA-17475 URL: https://issues.apache.org/jira/browse/KAFKA-17475 Project: Kafka

Re: [DISCUSS] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

Hi Matthias I will add deprecated with this `StreamsConfig#DUMMY_THREAD_INDEX` variable in this KIP. Best regards, Jiunn-Yang > Matthias J. Sax 於 2024年9月4日 清晨7:37 寫道： > > One more thing: there is also `StreamsConfig#DUMMY_THREAD_INDEX` which is an > unused variable. > > Can we also deprecat

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.7 #194

See

Re: [DISCUSS] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

One more thing: there is also `StreamsConfig#DUMMY_THREAD_INDEX` which is an unused variable. Can we also deprecate it as part of this KIP as a side cleanup (it's not worth to do a separate KIP about it, but given it's technically public API, we still need to cover it with a KIP) -Matthias

Re: [DISCUSS] KIP-1081: Graduation Steps for Features

On Fri, Aug 30, 2024, at 16:40, Matthias J. Sax wrote: > Great discussion. Also wanted to follow up with a few things. > > > I believe the term "usable" is not well defined leading to confusion... > I agree with Viktor that "usable" in the context of level 2 should just > mean: I can enable the f

Re: [DISCUSS] KIP-1085: Fix leaking *_DOC variables in StreamsConfig

Thanks for the KIP. I think it's a good clean. Given that it's a simple KIP, I don't expect much more discussions; feel free to start a vote. -Matthias On 8/28/24 10:37 PM, 黃竣陽 wrote: Hi Chia-Ping they can be package-private, right? Yes, your are right, I will address there variables on

Re: [DISCUSS] KAFKA-17316 and KAFKA-17423

On Tue, Sep 3, 2024, at 01:46, Claude Warren, Jr wrote: > Colin, > > I can see that it makes sense to replace the StandardAuthorizer so that there > are not 2 implementations. However, I think the testing framework should > remain so that in future new improved implementations of > StandardAut

Re: New release branch 3.9

On Mon, Sep 2, 2024, at 20:15, Luke Chen wrote: > Hi Colin, > > I've made KAFKA-17412 ( > PR ) as v3.9.0 blocker for > documenting the unclean leader election behavior change in KRaft mode. > This is jus

Re: New release branch 3.9

On Fri, Aug 30, 2024, at 11:53, Chia-Ping Tsai wrote: > hi Colin > > I open the https://issues.apache.org/jira/browse/KAFKA-17454 to be a > blocker for 3.9 since the e2e transactions_mixed_versions_test fail on > 3.9 definitely > > We will fix it tomorrow. > > Best, > Chia-Ping Thanks, Chia-Ping

Re: [EXT] Re: [VOTE] KIP-1033: Add Kafka Streams exception handler for exceptions occurring during processing

Hi Matthias and Sebastien, This sounds like a very small and low-risk PR for a KIP that is new in 3.9 (KIP-1033). I think we should be OK to cherry-pick it to 3.9, even though we're past code freeze. Please try to get it done this week, though :) best, Colin On Fri, Aug 30, 2024, at 19:03, Ma

[jira] [Resolved] (KAFKA-16502) Fix flaky EOSUncleanShutdownIntegrationTest#shouldWorkWithUncleanShutdownWipeOutStateStore

[ https://issues.apache.org/jira/browse/KAFKA-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-16502. - Resolution: Fixed > Fix flaky > EOSUncleanShutdownIntegrationTest#shouldWorkWithUnclean

[jira] [Reopened] (KAFKA-16502) Fix flaky EOSUncleanShutdownIntegrationTest#shouldWorkWithUncleanShutdownWipeOutStateStore

[ https://issues.apache.org/jira/browse/KAFKA-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax reopened KAFKA-16502: - > Fix flaky > EOSUncleanShutdownIntegrationTest#shouldWorkWithUncleanShutdownWipeOutStateSt

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

Thanks for the KIP, looking forward to it. +1 (non-binding) Regards, Apoorv Mittal On Tue, Sep 3, 2024 at 9:00 PM Matthias J. Sax wrote: > +1 (binding) > > On 9/3/24 8:56 AM, Andrew Schofield wrote: > > Thanks for the KIP. +1 (non-binding) > > > > Andrew > > >

[jira] [Resolved] (KAFKA-17467) Flaky test shouldStayDeadAfterTwoCloses org.apache.kafka.streams.processor.internals.GlobalStreamThreadTest

[ https://issues.apache.org/jira/browse/KAFKA-17467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-17467. - Resolution: Duplicate > Flaky test shouldStayDeadAfterTwoCloses > org.apache.kafka.stre

Re: [DISCUSS] KIP-1086: Add ability to specify a custom produce request parser.

Based on feedback from Kirk and Colin I added configuring the parser class name via server.properties, added some tests, and updated the docs to reflect this. I find the config file name by re-parsing the command line. If anyone knows a better way of passing KafkaConfig to static initialization,

Re: [DISCUSS] KIP-1071: Streams Rebalance Protocol

Ah, my bad -- I thought I refreshed the page to get the latest version which is why I was a bit confused when I couldn't find anything about the new tools which I had previously seen in the KIP. Sorry for the confusion and unnecessary questions S1. > You could imagine calling the initialize RPC >

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

+1 (binding) On 9/3/24 8:56 AM, Andrew Schofield wrote: Thanks for the KIP. +1 (non-binding) Andrew From: Lucas Brutschy Sent: 03 September 2024 16:02 To: dev@kafka.apache.org Subject: Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

Re: Possible bug in Authorize by ResourceTypeQue

> If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then > authorizeByResourceType should return true in all cases since the user > would have access for any operation on any undefined topic? It should return false if the user is denied all access using wildcard ACL. For example if you add an

[jira] [Resolved] (KAFKA-17468) Move kafka.log.remote.quota to storage module

[ https://issues.apache.org/jira/browse/KAFKA-17468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17468. Fix Version/s: 4.0.0 Resolution: Fixed > Move kafka.log.remote.quota to storage mod

[VOTE] KIP-1087: Removing intermediateTopicsOption from StreamsResetter

Hello All, I would like to call for a vote on KIP-1087: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1087%3A+Removing+intermediateTopicsOption+from+StreamsResetter The discussion can be found here: https://lists.apache.org/list?dev@kafka.apache.org:lte=1M:1087 Sincerely & Thanks, Arnav

[jira] [Created] (KAFKA-17474) Flaky tests in GlobalStreamThreadTest

Matthias J. Sax created KAFKA-17474: --- Summary: Flaky tests in GlobalStreamThreadTest Key: KAFKA-17474 URL: https://issues.apache.org/jira/browse/KAFKA-17474 Project: Kafka Issue Type: Test

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

Thanks for the KIP. +1 (non-binding) Andrew From: Lucas Brutschy Sent: 03 September 2024 16:02 To: dev@kafka.apache.org Subject: Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension Hi Bill, thanks for the KIP! +1 (binding) Lucas On Tue,

[jira] [Created] (KAFKA-17473) Speed Up ClientTelemetryTest

黃竣陽 created KAFKA-17473: --- Summary: Speed Up ClientTelemetryTest Key: KAFKA-17473 URL: https://issues.apache.org/jira/browse/KAFKA-17473 Project: Kafka Issue Type: Improvement Reporter: 黃竣陽

[jira] [Created] (KAFKA-17472) Speed Up DescribeConsumerGroupTest

黃竣陽 created KAFKA-17472: --- Summary: Speed Up DescribeConsumerGroupTest Key: KAFKA-17472 URL: https://issues.apache.org/jira/browse/KAFKA-17472 Project: Kafka Issue Type: Improvement Reporter

[jira] [Created] (KAFKA-17471) Speed Up ResetConsumerGroupOffsetTest

黃竣陽 created KAFKA-17471: --- Summary: Speed Up ResetConsumerGroupOffsetTest Key: KAFKA-17471 URL: https://issues.apache.org/jira/browse/KAFKA-17471 Project: Kafka Issue Type: Improvement Repor

Re: [DISCUSS] KIP-1034: Dead letter queue in Kafka Streams

Hi Bruno, > BC1 I see your point. I wonder if having a generic and separate tool outside of StreamsReset to reset a topic would make sense. Some community projects have this feature (empty topics) and that's true that it could be quite useful, e.g. AKHQ. > BC3 Good point, this is not really a bui

Re: [VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

Hi Bill, thanks for the KIP! +1 (binding) Lucas On Tue, Sep 3, 2024 at 4:49 PM Bill Bejeck wrote: > > Hi All, > > I'd like to call for a vote on KIP-1076 > > (discussion can be fo

[VOTE] KIP-1076: Metrics for client applications a KIP-714 extension

Hi All, I'd like to call for a vote on KIP-1076 (discussion can be found here ) -Bill

Re: [DISCUSS] KIP-1076: Metrics for client applications a KIP-714 extension

Thanks for commenting, Matthias. Why did you switch from passing in a `Collection` to a single metric? With the changes in the implementation it became obvious that was the necessary approach. Since it seems the discussion has concluded, I'll start a vote now. Thanks to all for the comments an

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

See

Re: [DISCUSS] KIP-1034: Dead letter queue in Kafka Streams

Hi Damien, BC1 > In my opinion DLQ topics should be viewed as a sink topic and > AFAIK, this tool does not clean up sink topics. Maybe, but one could also argue DLQ topics are part of the runtime because is collects errors occurred during the runtime that might be specific to given execution

[jira] [Created] (KAFKA-17470) CommitRequestManager should record failed request only once even if multiple errors in response

Lianet Magrans created KAFKA-17470: -- Summary: CommitRequestManager should record failed request only once even if multiple errors in response Key: KAFKA-17470 URL: https://issues.apache.org/jira/browse/KAFKA-1747

Re: [DISCUSS] KIP-1034: Dead letter queue in Kafka Streams

Hi Bruno, Thanks a lot for your comments! > BC1 > Do you also plan to add an argument to the StreamsResetter tool to > delete the default DLQ topic when a Streams app is reset? Good point, I did not think about the StreamsResetter tool. Thinking out loud, I am not sure if it is a good idea to add

Re: Possible bug in Authorize by ResourceTypeQue

Followup2: your answer speaks directly to "WRITE" access. My example was READ access. So the question method is answering then is: Does the user have access to READ any TOPIC? And that is further restricted by the requestContext host is it not? On Tue, Sep 3, 2024 at 2:10 PM Claude Warren, Jr

Re: Possible bug in Authorize by ResourceTypeQue

Followup: If ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true" then authorizeByResourceType should return true in all cases since the user would have access for any operation on any undefined topic? On Tue, Sep 3, 2024 at 2:08 PM Claude Warren, Jr wrote: > I am working on a replacement for the

Re: Possible bug in Authorize by ResourceTypeQue

I am working on a replacement for the StandardAuthorizer and my implementation DENIED while the standard implementation ALLOWED. In reading the specs I thought it should be DENIED. But your statement makes it clear that I misread. Thank you, Claude On Tue, Sep 3, 2024 at 1:14 PM Rajini Sivaram

Re: [DISCUSS] KIP-1034: Dead letter queue in Kafka Streams

Hi, Thanks for the updates! I have a couple of comments. BC1 Do you also plan to add an argument to the StreamsResetter tool to delete the default DLQ topic when a Streams app is reset? BC2 Would it make sense to add errors.deadletterqueue.topic.name to the ErrorHandlerContext in case that

Re: [DISCUSS] KIP-1043: Administration of groups

Hi, I’ve spent some time working with clusters containing groups of multiple types, fixing problems and improving error handling. I’ve simplified the KIP so that it just adds kafka-groups.sh and improves the error handling for describing groups of the wrong type. With the other improvements I’ve a

Re: Possible bug in Authorize by ResourceTypeQue

Hi Claude, `authorizeByResourceType` doesn't grant access to any specific topic, it grants access to idempotent write if the user has access to write to any topic (which may or may not exist). In this case, ALLOW_EVERYONE_IF_NO_ACL_IS_FOUND_CONFIG = "true", so `User:alice` can write to a topic tha

[jira] [Created] (KAFKA-17469) Move appropriate classes and interfaces to the new share module

Sushant Mahajan created KAFKA-17469: --- Summary: Move appropriate classes and interfaces to the new share module Key: KAFKA-17469 URL: https://issues.apache.org/jira/browse/KAFKA-17469 Project: Kafka

Possible bug in Authorize by ResourceTypeQue

*Setup:* Superuser = "User:superman" ACLs added to system new StandardAcl(TOPIC, "foo", PREFIXED, "User:alice", WILDCARD, READ, DENY) new StandardAcl(TOPIC, "foobar", LITERAL, "User:alice", WILDCARD, READ, ALLOW) new StandardAcl(TOPIC, "foo", PREFIXED, "User:bob", WILDCARD, READ, ALLOW) ALLOW_EVE

[jira] [Resolved] (KAFKA-17294) Handle retriable errors when fetching offsets in new consumer

[ https://issues.apache.org/jira/browse/KAFKA-17294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17294. Fix Version/s: 4.0.0 Resolution: Fixed > Handle retriable errors when fetching offs

[jira] [Resolved] (KAFKA-17170) Add test to ensure new consumer acks reconciled assignment even if first HB with ack lost

[ https://issues.apache.org/jira/browse/KAFKA-17170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lianet Magrans resolved KAFKA-17170. Fix Version/s: 4.0.0 Reviewer: Lianet Magrans Resolution: Fixed > Add test

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #3262

See

Re: [VOTE] KIP-1074: Allow the replication of user internal topics

Hi Patrik, Thanks for working on this. +1 from me (binding). Best, Viktor On Wed, Aug 28, 2024 at 1:34 PM Patrik Marton wrote: > Hi all, > > As the proposal is finalized, and there was no new feedback in the past > week, I would like to open voting for KIP-1074 > < > https://cwiki.apache.org/c

Re: [DISCUSS] KAFKA-17316 and KAFKA-17423

Colin, I can see that it makes sense to replace the StandardAuthorizer so that there are not 2 implementations. However, I think the testing framework should remain so that in future new improved implementations of StandardAuthorizerData can be easily implemented and tested. I will put forward a

[jira] [Created] (KAFKA-17468) Move kafka.log.remote.quota to storage module

Mickael Maison created KAFKA-17468: -- Summary: Move kafka.log.remote.quota to storage module Key: KAFKA-17468 URL: https://issues.apache.org/jira/browse/KAFKA-17468 Project: Kafka Issue Type:

[jira] [Created] (KAFKA-17467) Flaky test shouldStayDeadAfterTwoCloses org.apache.kafka.streams.processor.internals.GlobalStreamThreadTest

Igor Soarez created KAFKA-17467: --- Summary: Flaky test shouldStayDeadAfterTwoCloses org.apache.kafka.streams.processor.internals.GlobalStreamThreadTest Key: KAFKA-17467 URL: https://issues.apache.org/jira/browse/KAFK

[jira] [Resolved] (KAFKA-17430) Move RequestChannel.Metrics and RequestChannel.RequestMetrics to server module

[ https://issues.apache.org/jira/browse/KAFKA-17430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mickael Maison resolved KAFKA-17430. Fix Version/s: 4.0.0 Resolution: Fixed > Move RequestChannel.Metrics and RequestCha