[jira] [Resolved] (KAFKA-12728) Version upgrades: gradle (6.8.3 -->> 7.0.1) and gradle shadow plugin (6.1.0 -->> 7.0.0)

[ https://issues.apache.org/jira/browse/KAFKA-12728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dejan Stojadinović resolved KAFKA-12728. Resolution: Done Solving as *done* (related code is merged into trunk). > Version

Re: [DISCUSS] KIP-739: Block Less on KafkaProducer#send

Hello Nakamura, Thanks for proposing this change. I can see how the blocking behaviour can be a problem when integrating with reactive frameworks such as Akka. One of the questions I would have is how you would handle back pressure and avoid memory exhaustion when the producer's buffer is full and

Re: Recover partitions from a failed broker leader which is the only replica in isr.

Hi JD, You can enable unclean leader election (disabled by default) to use ex-ISR followers as fallbacks for new leaders - but be mindful of data loss. Thanks, Alexandre Le mar. 10 nov. 2020 à 06:33, JD Zheng a écrit : > > Hi, everyone, > > Not sure if this is the right place to ask this questi

[jira] [Created] (KAFKA-12793) KIP-693 Client-side Circuit Breaker for Partition Write Errors

KahnCheny created KAFKA-12793: - Summary: KIP-693 Client-side Circuit Breaker for Partition Write Errors Key: KAFKA-12793 URL: https://issues.apache.org/jira/browse/KAFKA-12793 Project: Kafka Iss

Re: Recover partitions from a failed broker leader which is the only replica in isr.

A better option is to use the elect leaders command. You have to be careful still, but the edge is not as sharp as the config. Ismael On Sun, May 16, 2021, 4:32 AM Alexandre Dupriez wrote: > Hi JD, > > You can enable unclean leader election (disabled by default) to use > ex-ISR followers as fal

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

See

[DISCUSS] KIP-740: Replace the public TaskId class with an interface

I'm moving the discussion on KIP-740 to an actual [DISCUSS] thread since it turned out to be more nuanced and grew in scope since I initially proposed it. Thanks John for the suggestions/questions on the [VOTE] thread, I have copied them over and addressed them below. Before that, I just want to a

[jira] [Created] (KAFKA-12794) Trailing JSON tokens in DescribeProducersRequest.json can cause parse errors in some JSON parsers

Nathan Lincoln created KAFKA-12794: -- Summary: Trailing JSON tokens in DescribeProducersRequest.json can cause parse errors in some JSON parsers Key: KAFKA-12794 URL: https://issues.apache.org/jira/browse/KAFKA-12

Re: [DISCUSS] KIP-740: Replace the public TaskId class with an interface

Sorry, one correction regarding the discussion on naming below: the other con for reusing TaskId as the interface name is that we would not be able to follow the standard getter naming conventions and introduce new taskId() APIs to replace the deprecated ones, as the deprecated methods have already

[jira] [Created] (KAFKA-12795) Create kafka connector use chinese character failed

pengWei Dou created KAFKA-12795: --- Summary: Create kafka connector use chinese character failed Key: KAFKA-12795 URL: https://issues.apache.org/jira/browse/KAFKA-12795 Project: Kafka Issue Type:

Re: [VOTE] KIP-740: Use TaskId instead of String for the taskId field in TaskMetadata

Thanks John. I have moved the discussion over to a [DISCUSS] thread, where it should have been taking place all along. I'll officially kick off the vote again, but since this KIP has been through a significant overhauled since it's initial proposal, the previous votes cast will be invalidated. Plea

Re: [DISCUSS] KIP-740: Replace the public TaskId class with an interface

Sophie, Thanks for the nice summary. Originally I'm leaning towards option 2) since changing this name to others could be a pretty large conceptual change to users, and I think the concerns you raised is good as well that we cannot reuse the `taskId()` function names any more.. After pondering on

Testing KRaft mode

Hi, I was testing the early access preview of the new ZooKeeper-less mode and noticed two things I wanted to bring up here. My testing scenario was a cluster of three Kafka nodes in combined mode and a single Kafka Connect node, all running via Docker Compose. * I stopped two of the Kafka nodes;

Re: [DISCUSS] KIP-740: Replace the public TaskId class with an interface

> > Changing `TaskId` to an abstract class and deprecate all util functions / > fields that we do not > want to expose any longer I had considered doing exactly this, where we just convert the existing public TaskId class to an interface or an abstract class rather than introducing a new one, but