[jira] [Created] (KAFKA-17034) Tweak some descriptions in `FeatureUpdate`

Chia-Ping Tsai created KAFKA-17034: -- Summary: Tweak some descriptions in `FeatureUpdate` Key: KAFKA-17034 URL: https://issues.apache.org/jira/browse/KAFKA-17034 Project: Kafka Issue Type: Im

Re: [DISCUSS] Apache Kafka 3.9.0 release

Hello, Can I include KIP-1025 in this release? It's currently in the voting stage, I hope it can receive enough votes by next week. Thanks. On Tue, Jun 18, 2024

[jira] [Reopened] (KAFKA-17015) ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Should not be deprecated and throw an exception

[ https://issues.apache.org/jira/browse/KAFKA-17015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reopened KAFKA-17015: > ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Should not be > deprecated an

[jira] [Resolved] (KAFKA-17015) ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Should not be deprecated and throw an exception

[ https://issues.apache.org/jira/browse/KAFKA-17015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17015. Resolution: Won't Fix > ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Shou

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hey folks, Great discussion! Re: throwing exceptions from send(). send() is documented to throw KafkaException, so if the application doesn't handle it, it should be a bug. Now, it does have a note that API exceptions wouldn't be thrown, not sure if we have code that relies on that. There is a

[jira] [Resolved] (KAFKA-17015) ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Should not be deprecated and throw an exception

[ https://issues.apache.org/jira/browse/KAFKA-17015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dujian0068 resolved KAFKA-17015. Resolution: Fixed > ContextualRecord#hashCode()、ProcessorRecordContext#hashCode() Should not be >

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

See

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

One quick thought: if a user invokes Producer::abortTransaction from within a producer callback today, even in the midst of an ongoing call to Producer::commitTransaction, what is the behavior? Would it be reasonable to support this behavior as a way to allow error handling to take place during imp

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

My point it, that it does not seem to be safe to allow users to ignore errors with an implicit flush, and I think it's better to only allow it with (ie, after) an explicit flush(). My reasoning is, that users should make a decision to ignore errors or not, before calling `commitTx()`, but afte

[jira] [Created] (KAFKA-17033) Consider replacing the directory id Optional with just Uuid

José Armando García Sancio created KAFKA-17033: -- Summary: Consider replacing the directory id Optional with just Uuid Key: KAFKA-17033 URL: https://issues.apache.org/jira/browse/KAFKA-17033

Re: Herder#requestTaskReconfiguration

Hi John, Thanks for the question! That method is used when the Connector notifies the runtime it observed an event that would require a new set of task configs. For example, the MirrorSourceConnector calls ConnectorContext#requestTaskReconfiguration() when a new topic appears in the input cluster

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Transaction verification is a concept from KIP-890 referring to the verification that a partition has been added to the transaction. It's not a huge deal, but maybe we don't want to overload the terminology. For option 2, I was a little confused by this > when commitTx is called, there is still

[jira] [Resolved] (KAFKA-16965) Add a "root cause" exception as a nested exception to TimeoutException for Producer

[ https://issues.apache.org/jira/browse/KAFKA-16965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias J. Sax resolved KAFKA-16965. - Fix Version/s: 3.9.0 Resolution: Fixed > Add a "root cause" exception as a nested

[jira] [Created] (KAFKA-17032) NioEchoServer should generate meaningful id instead of incremential number

Chia-Ping Tsai created KAFKA-17032: -- Summary: NioEchoServer should generate meaningful id instead of incremential number Key: KAFKA-17032 URL: https://issues.apache.org/jira/browse/KAFKA-17032 Projec

Re: 回复: apply a jira account

Thanks. Found an account by name. You should be all set. -Matthias On 6/23/24 10:38 PM, zhou zhengke wrote: Thanks for reply. I checked again, and get some useful info: email : madzh...@gmail.com Desired user name: zzzk1 real (public) name: zhengke zhou

Re: [VOTE] KIP-1022 Formatting and Updating Features

My understanding is that the tools that don't rely on ApiVersions should still return 0s when it is the correct value. I believe these commands do not require this API and thus can show 0 as versions. Likewise, when the old ApiVersionsRequest is used to describe features, we can't return 0 version

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Agreed. Options 1 and 3 are safe. Option 2 is not. I’d be happy with 3a as the way. I suggest “TRANSACTION VERIFIED”. There isn’t really precedent for options in the producer API. We could use an enum, which is easy to use and not very future-proof. Or we could use a class like the admin API do

Re: [VOTE] KIP-1022 Formatting and Updating Features

Hi, Colin, Thanks for the update. The proposed change seems reasonable to me. Just one clarification. The KIP can show version 0 of certain features with version-mapping and feature-dependencies. Will that part change? For example, will the tool show version 0 features with --release-version 3.8

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

I am ok either way (ie, flush or commit), but I think we need to define exact semantics, and I think there is some subtle thing to consider: 1) flush(Options) Example: send(...) send(...) flush(ignoreErrors) // at this point, we know that all Futures are completed and all Callback

[jira] [Reopened] (KAFKA-16990) Unrecognised flag passed to kafka-storage.sh in system test

[ https://issues.apache.org/jira/browse/KAFKA-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justine Olshan reopened KAFKA-16990: > Unrecognised flag passed to kafka-storage.sh in system test > --

[jira] [Created] (KAFKA-17031) Make configurations public

Christo Lolov created KAFKA-17031: - Summary: Make configurations public Key: KAFKA-17031 URL: https://issues.apache.org/jira/browse/KAFKA-17031 Project: Kafka Issue Type: Sub-task

Re: [DISCUSS] KIP-1060: Expose advertised.listeners for KRaft controllers

Hi Gantigmaa, I am implementing this as part of the KIP-853 implementation. I have a PR for this here: https://github.com/apache/kafka/pull/16235 Take a look at my KafkaConfig changes and related code. Thanks On Mon, Jun 24, 2024 at 8:04 AM Gantigmaa Selenge wrote: > > Hello > > I would like t

[jira] [Resolved] (KAFKA-16990) Unrecognised flag passed to kafka-storage.sh in system test

[ https://issues.apache.org/jira/browse/KAFKA-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justine Olshan resolved KAFKA-16990. Resolution: Fixed > Unrecognised flag passed to kafka-storage.sh in system test >

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi Chris, That works for me too. I slightly prefer an option on flush(), but what you suggested works too. Thanks, Andrew > On 24 Jun 2024, at 15:14, Chris Egerton wrote: > > Hi Andrew, > > I like a lot of what you said, but I still believe it's better to override > commitTransaction than flush

[jira] [Resolved] (KAFKA-17013) RequestManager#ConnectionState#toString() should use %s

[ https://issues.apache.org/jira/browse/KAFKA-17013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17013. Fix Version/s: 3.9.0 Resolution: Fixed > RequestManager#ConnectionState#toString()

RE: Re:[DISCUSS] KIP-1009: Add Broker-level Throttle Configurations

Hi Ria, I think this KIP will be a great addition! My current use case for replication throttling is during broker recovery after data loss; in this situation we would want to throttle the replication of all topics to avoid impacting producer/consumer traffic, which would be much easier with br

[jira] [Created] (KAFKA-17030) Voters should not assume that the leader will send them BeginQuorumEpoch requests

José Armando García Sancio created KAFKA-17030: -- Summary: Voters should not assume that the leader will send them BeginQuorumEpoch requests Key: KAFKA-17030 URL: https://issues.apache.org/jira/browse/

[jira] [Created] (KAFKA-17029) SetSchemaMetadata smt throws DataException when avro schema is primitive type

Mark McDonald created KAFKA-17029: - Summary: SetSchemaMetadata smt throws DataException when avro schema is primitive type Key: KAFKA-17029 URL: https://issues.apache.org/jira/browse/KAFKA-17029 Proje

[jira] [Created] (KAFKA-17028) FindCoordinator v6 initial implementation

Andrew Schofield created KAFKA-17028: Summary: FindCoordinator v6 initial implementation Key: KAFKA-17028 URL: https://issues.apache.org/jira/browse/KAFKA-17028 Project: Kafka Issue Type:

[jira] [Resolved] (KAFKA-17004) MINOR: Remove extra synchronized blocks in SharePartitionManager

[ https://issues.apache.org/jira/browse/KAFKA-17004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhinav Dixit resolved KAFKA-17004. --- Fix Version/s: 4.0.0 3.9.0 Resolution: Fixed > MINOR: Remove extra

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi Andrew, I like a lot of what you said, but I still believe it's better to override commitTransaction than flush. Users will already have to manually opt in to ignoring errors encountered during transactions, and we can document recommended usage (i.e., explicitly invoking flush() before invokin

[jira] [Created] (KAFKA-17027) Inconsistent casing in Selector metrics tags

Mickael Maison created KAFKA-17027: -- Summary: Inconsistent casing in Selector metrics tags Key: KAFKA-17027 URL: https://issues.apache.org/jira/browse/KAFKA-17027 Project: Kafka Issue Type:

[jira] [Resolved] (KAFKA-16967) NioEchoServer fails to register connection and causes flaky failure

[ https://issues.apache.org/jira/browse/KAFKA-16967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-16967. Fix Version/s: 3.9.0 Resolution: Fixed > NioEchoServer fails to register connection

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi Alieh, Thanks for driving this. Unfortunately, there are many parts of the API which are a bit unfortunate and it’s tricky to make small improvements that don’t have downsides. I don’t like the idea of using a configuration because configuration is often outside the application and changing the

Re: [DISCUSS] KIP-1059: Enable the Producer flush() method to clear the latest send() error

Hi all, Thanks for the interesting discussion. I assume that now the main questions are as follows: 1. Do we need to transit the transcation to the error state for API exceptions? 2. Should we throw the API exception in `send()` instead of returning a future error? 3. If the answer to question (1

[DISCUSS] KIP-1060: Expose advertised.listeners for KRaft controllers

Hello I would like to start a discussion for KIP-1060 that suggests allowing advertised.listeners configuration for KRaft controllers, which is currently forbidden. https://cwiki.apache.org/confluence/display/KAFKA/KIP-1060%3A+Expose+advertised.listeners+for+KRaft+controllers Thanks, Tina Seleng

[jira] [Resolved] (KAFKA-16999) Integrate persister read API in Partition leader initilization

[ https://issues.apache.org/jira/browse/KAFKA-16999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apoorv Mittal resolved KAFKA-16999. --- Resolution: Done > Integrate persister read API in Partition leader initilization >

[jira] [Resolved] (KAFKA-16749) Implement share fetch messages

[ https://issues.apache.org/jira/browse/KAFKA-16749?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apoorv Mittal resolved KAFKA-16749. --- Resolution: Done > Implement share fetch messages > -- > >

[jira] [Resolved] (KAFKA-16748) Implement share response handling in SharePartitionManager

[ https://issues.apache.org/jira/browse/KAFKA-16748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Apoorv Mittal resolved KAFKA-16748. --- Resolution: Fixed > Implement share response handling in SharePartitionManager > ---

RE: Herder#requestTaskReconfiguration

Hi Folks, Any ideas? From: talljhawk...@gmail.com Sent: Thursday, June 13, 2024 10:36 AM To: dev@kafka.apache.org Subject: Herder#requestTaskReconfiguration Hi Folks, what is the purpose of this method please? /** * Requests reconfiguration of the tasks of a connector. This sh

[jira] [Created] (KAFKA-17026) Implement updateCachedAndOffsets functionality on LSO movement

Abhinav Dixit created KAFKA-17026: - Summary: Implement updateCachedAndOffsets functionality on LSO movement Key: KAFKA-17026 URL: https://issues.apache.org/jira/browse/KAFKA-17026 Project: Kafka

[jira] [Reopened] (KAFKA-16551) add integration test for ClusterTool

[ https://issues.apache.org/jira/browse/KAFKA-16551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai reopened KAFKA-16551: > add integration test for ClusterTool > > >

[DISCUSS] KIP-1061: Allow exporting SCRAM credentials

Hi all, I'd like to kick off discussion for KIP-1061 which proposes a way to export SCRAM credentials: https://cwiki.apache.org/confluence/display/KAFKA/KIP-1061%3A+Allow+exporting+SCRAM+credentials Please have a look. Looking forward to hearing your thoughts! Regards, Gaurav

Re: [DISCUSS] Apache Kafka 3.8.0 release

Hi all, We currently have a couple of blockers for the 3.8.0 release. These are the following: - Reverting commit KAFKA-16154 and mark latest production metadata as 3.8.0: https://github.com/apache/kafka/pull/16400 - Fix some failing system tests: https://github.com/apache/kafka/pull/16420 Can we