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

See Changes: -- [...truncated 504777 lines...] [2022-09-07T05:40:03.402Z] > Task :connect:api:testClasses UP-TO-DATE [2022-09-07T05:40:03.402Z] > Task :connect:api:testJar

[jira] [Created] (KAFKA-14205) Document how to recover from kraft controller disk failure

Jose Armando Garcia Sancio created KAFKA-14205: -- Summary: Document how to recover from kraft controller disk failure Key: KAFKA-14205 URL: https://issues.apache.org/jira/browse/KAFKA-14205

RE: Problem with Kafka KRaft 3.1.X

I've had similar errors cause by mmap counts; try with vm.max_map_count=262144 On 2022/09/01 23:57:54 Paul Brebner wrote: > Hi all, > > I've been attempting to benchmark Kafka KRaft version for an ApacheCon talk > and have identified 2 problems: > > 1 - it's still impossible to create large

[jira] [Resolved] (KAFKA-14197) Kraft broker fails to startup after topic creation failure

[ https://issues.apache.org/jira/browse/KAFKA-14197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colin McCabe resolved KAFKA-14197. -- Resolution: Duplicate > Kraft broker fails to startup after topic creation failure >

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.3 #59

See Changes: -- [...truncated 573767 lines...] [2022-09-06T20:11:16.653Z] [2022-09-06T20:11:16.653Z] org.apache.kafka.streams.integration.TableTableJoinIntegrationTest >

[jira] [Created] (KAFKA-14204) QuorumController must correctly handle overly large batches

Colin McCabe created KAFKA-14204: Summary: QuorumController must correctly handle overly large batches Key: KAFKA-14204 URL: https://issues.apache.org/jira/browse/KAFKA-14204 Project: Kafka

[jira] [Created] (KAFKA-14203) KRaft broker should disable snapshot generation after error replaying the metadata log

Jose Armando Garcia Sancio created KAFKA-14203: -- Summary: KRaft broker should disable snapshot generation after error replaying the metadata log Key: KAFKA-14203 URL:

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

See Changes: -- [...truncated 507466 lines...] [2022-09-06T18:58:20.400Z] [INFO] [2022-09-06T18:58:20.400Z] [INFO] --- maven-archetype-plugin:2.2:jar (default-jar) @

Re: [DISCUSS] KIP-857: Streaming recursion in Kafka Streams

The more I think about this, the more I think that automatic repartitioning is not required in the "recursively" method itself. I've removed references to this from the KIP, which further simplifies everything. I don't see any need to restrict users from repartitioning, either before, after or

Re: [DISCUSS] KIP-857: Streaming recursion in Kafka Streams

Hi Guozhang, I mentioned this in the "Rejected Alternatives" section. Repartitioning gives us several significant advantages over using an explicit topic and "to": - Repartition topics are automatically created and managed by the Streams runtime; explicit topics have to be created and

[jira] [Created] (KAFKA-14202) IQv2: Expose binary store schema to store implementations

John Roesler created KAFKA-14202: Summary: IQv2: Expose binary store schema to store implementations Key: KAFKA-14202 URL: https://issues.apache.org/jira/browse/KAFKA-14202 Project: Kafka

Re: [DISCUSS] KIP-857: Streaming recursion in Kafka Streams

Hello Nick, Thanks for the re-written KIP! I read through it again, and so far have just one quick question on top of my head regarding repartitioning: it seems to me that when there's an intermediate topic inside the recursion step, then using this new API would basically give us the same

[jira] [Resolved] (KAFKA-14179) Improve docs/upgrade.html to talk about metadata.version upgrades

[ https://issues.apache.org/jira/browse/KAFKA-14179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Armando Garcia Sancio resolved KAFKA-14179. Fix Version/s: (was: 3.3.0) Resolution: Duplicate >

Re: [DISCUSS] KIP-857: Streaming recursion in Kafka Streams

Hi everyone, I've re-written the KIP, with a new design that I think resolves the issues you highlighted, and also simplifies usage. https://cwiki.apache.org/confluence/display/KAFKA/KIP-857%3A+Streaming+recursion+in+Kafka+Streams Note: I'm still working out the "automatic repartitioning" in my

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

See Changes: -- [...truncated 501969 lines...] [2022-09-06T15:33:18.315Z] [2022-09-06T15:33:18.315Z] StreamsAssignmentScaleTest >

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.2 #76

See Changes: -- [...truncated 548918 lines...] [2022-09-06T13:10:54.726Z] [2022-09-06T13:10:54.726Z] org.apache.kafka.streams.integration.SuppressionIntegrationTest >

Re: [DISCUSS] KIP-848: The Next Generation of the Consumer Rebalance Protocol

Hi Jun, I have updated the KIP to include your feedback. I have also tried to clarify the parts which were not cleared. Best, David On Fri, Sep 2, 2022 at 4:18 PM David Jacot wrote: > > Hi Jun, > > Thanks for your feedback. Let me start by answering your questions > inline and I will update

Re: [DISCUSS] KIP-864: Add End-To-End Latency Metrics to Connectors

Hi Sagar and Yash, > the way it's defined in https://kafka.apache.org/documentation/#connect_monitoring for the metrics 4.1. Got it. Add it to the KIP. > The only thing I would argue is do we need sink-record-latency-min? Maybe we > could remove this min metric as well and make all of the 3 e2e

Re: [DISCUSSION] KIP-865: Support --bootstrap-server in kafka-streams-application-reset

Sure, no problem. Thread name updated. Link to KIP - https://cwiki.apache.org/confluence/display/KAFKA/KIP-865%3A+Support+--bootstrap-server+in+kafka-streams-application-reset

Re: [DISCUSSION] KIP-864: Support --bootstrap-server in kafka-streams-application-reset

Hello. Do we still want to make parameter names consistent in tools? If yes, please, share your feedback on KIP. > 31 авг. 2022 г., в 11:50, Николай Ижиков написал(а): > > Hello. > > I would like to start discussion on small KIP [1] > The goal of KIP is to add the same —boostrap-server