Re: [DISCUSS] KIP-1150 Diskless Topics

I have some nits - it may be useful to a) group all the KIP email threads in the main one (just a bunch of links to everything) b) create the email threads It's a bit hard to track it all - for example, I was searching for a discuss thread for KIP-1165 for a while; As far as I can tell, it does

Re: [DISCUSS] KIP-1176: Tiered Storage for Active Log Segment

Have we considered using the traditional replication path to store the actual metadata for the topic/partition? I know the KIP says "The main purpose of FollowerFetchRequest/FollowerFetchResponse is now just to update the offsets and high watermark between leader and follower.", but what if we

Re: [DISCUSS] KIP-1176: Tiered Storage for Active Log Segment

Thanks for the awesome proposal! Few questions: 1) can we have more detail around the proposed deployment model in GCP/Azure? As of reading, the KIP seems overly focused on AWS - but the feature will need to have viable support for the other two major clouds, right? In particular it would be n

Re: [DISCUSS] KIP-1150 Diskless Topics

This is an amazing initiative. Huge kudos for driving it. We should incorporate it one way or another. I have a suggestion I'd like to hear your thoughts on. I'm cognizant of the effort required for KIP-1150 so I don't necessarily want to increase the scope - but thinking about this early on ca

Re: Fetch Request performing remote KIP-405 reads gotcha

e together. > Also "remote.fetch.max.wait.ms" config is also a good place to add this > missing info. > > Thanks. > Luke > > On Thu, Mar 27, 2025 at 4:27 AM Stanislav Kozlovski < > stanislavkozlov...@apache.org> wrote: > > > Hey all, > > > > I was doing

Fetch Request performing remote KIP-405 reads gotcha

Hey all, I was doing a deep dive on the internals of KIP-405's read path and I was surprised to learn that the broker only fetches remote data for ONE partition in a given FetchRequest. In other words, if a consumer sends a FetchRequest requesting 50 topic-partitions, and each partition's requeste

Re: 回复： [DISCUSS] KIP-1134: Virtual Clusters in Kafka

This is a super cool proposal. Thank you for it! 1) The KIP mentions VCs are allowed ALTER_CONFIG, but doesn't mention what configs will be allowed to get modified and what not. There are a few broker-level configs that shouldn't be modifiable by any single VC imo - https://github.com/apache/ka

Re: Metadata requests for subset of partitions

> > It's certainly been a topic that's come up before. In certain situations > > the current approach is a bit heavy-handed. The current approach for > > fetching metadata has a number of benefits: it keeps the protocol from > > being too chatty, which reduces load on the brokers and makes maintain

Re: Metadata requests for subset of partitions

ad22dec815358/clients/src/main/resources/common/message/MetadataResponse.json#L77-L90 Best, Stan On 2025/02/28 12:49:44 Michał Łowicki wrote: > On Fri, Feb 28, 2025 at 10:10 AM Stanislav Kozlovski < > stanislavkozlov...@apache.org> wrote: > > > > > It's

Re: [VOTE] 4.0.0 RC0

+1 On 2025/02/24 23:07:12 Christopher Shannon wrote: > If the purpose of this is not to vote but just to evaluate the RC then I > think it would be better to not use the [VOTE] tag for the subject as that > is super confusing. > > On Mon, Feb 24, 2025 at 10:45 AM Ismael Juma wrote: > > > Hi Mic

Re: [DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

f the partition IS reasigning, then we check `currentReassignmentTargetReplicaSet.size != newTargetReplicaSet.size` Best, Stan On 2025/02/05 14:46:08 Kuan Po Tseng wrote: > Hi all, > > After discussing with Stanislav Kozlovski, I plan to continue implementing > this KIP. > Howeve

Re: [DISCUSS] KIP-1123: Rack-aware partitioning for Kafka Producer

Wow, I am super happy to see this KIP! Thanks for publishing it! I threw the idea out there last week in an article of mine about calculating Kafka costs[1] > [FUTURE KIP] - a Produce to Local Leader KIP, similar to KIP-392, can be > introduced to eliminate producer inter-AZ network costs for t

Re: [VOTE] 3.7.0 RC4

has reached the maven central repository. > > Ismael > > On Tue, Feb 27, 2024 at 9:49 AM Stanislav Kozlovski > wrote: > > > The thinking is that it is available for use - and it is in maven > central - > > https://central.sonatype.com/artifact/org.apache.kafka/ka

[ANNOUNCE] Apache Kafka 3.7.0

Provenzano, Purshotam Chauhan, Qichao Chu, Matthias J. Sax, Rajini Sivaram, Renaldo Baur Filho, Ritika Reddy, Robert Wagner, Rohan, Ron Dagostino, Roon, runom, Ruslan Krivoshein, rykovsi, Sagar Rao, Said Boudjelda, Satish Duggana, shuoer86, Stanislav Kozlovski, Taher Ghaleb, Tang Yunzi, TapDang, Taras

Re: [VOTE] 3.7.0 RC4

; See "Wait for about a day for the artifacts to show up in apache mirror > (releases, public group) and maven central (mvnrepository.com or maven.org > )." > in the release process wiki. > > -- > Divij Vaidya > > > > On Tue, Feb 27, 2024 at 4:43 PM Stanisla

Re: [VOTE] 3.7.0 RC4

ifact/org.apache.kafka/kafka Am I free to announce the release, or should I wait more for MVNRepository to get up to date? For what it's worth, I "Released" the files 24 hours ago On Mon, Feb 26, 2024 at 10:42 AM Stanislav Kozlovski wrote: > > This vote passes with *10 +1 votes* (

Re: [VOTE] 3.7.0 RC4

llow ASAP. On Mon, Feb 26, 2024 at 10:42 AM Stanislav Kozlovski wrote: > > This vote passes with *10 +1 votes* (3 bindings) and no 0 or -1 votes. > > +1 votes > > PMC Members (binding): > * Mickael Maison > * Justine Olshan > * Divij Vaidya > > Community (non-bi

Re: [VOTE] 3.7.0 RC4

wrote: > Hi, > > Thanks for sorting out the docs issues. > +1 (binding) > > Mickael > > On Fri, Feb 23, 2024 at 11:50 AM Stanislav Kozlovski > wrote: > > > > Some quick updates: > > > > There were some inconsistencies between the documentation in

Re: [VOTE] 3.7.0 RC4

e. After this we follow the > > > > steps from here: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Release+Process#ReleaseProcess-Afterthevotepasses > > > > > > > > 2. Upload artifacts to maven

Re: [VOTE] 3.7.0 RC4

12-3.9.4 is missing in license file > > > > scala-reflect-2.12.18 is missing in license file > > > > ``` > > > > > > > > ## Long running tests for memory leak (on ARM machine with zstd) > > > > > >

Re: [VOTE] 3.7.0 RC4

just have some flakes On Sun, Feb 18, 2024 at 10:45 AM Stanislav Kozlovski wrote: > The upgrade test passed -> > https://confluent-kafka-branch-builder-system-test-results.s3-us-west-2.amazonaws.com/system-test-kafka-branch-builder--1708103771--apache--3.7--bb6990114b/2024-02-16--001./2

Re: [VOTE] 3.7.0 RC4

tps://jenkins.confluent.io/job/system-test-kafka-branch-builder/6062/ On Fri, Feb 16, 2024 at 6:39 PM Stanislav Kozlovski wrote: > Thanks all for the help in verifying. > > I have updated > https://gist.github.com/stanislavkozlovski/820976fc7bfb5f4dcdf9742fd96a9982 > with the system tests. > Ther

Re: [VOTE] 3.7.0 RC4

; > > > > > > On 15 Feb 2024, at 05:07, Paolo Patierno > > wrote: > > > > > > > > +1 (non-binding). I used the staged binaries with Scala 2.13 and > mostly > > > > focused on the ZooKeeper to KRaft migration with multiple test

Re: [VOTE] 3.7.0 RC4

and the > staged > > Maven artifacts to run my tests. All seems to work fine. Thanks. > > > > Jakub > > > > On Fri, Feb 9, 2024 at 4:20 PM Stanislav Kozlovski > > wrote: > > > > > Hello Kafka users, developers and client-developers, > > &

Re: Apache Kafka 3.7.0 Release

ting that > > "Kafka > > > cluster will be unavailable during KRaft migration rollback". > > > The impact for this issue is that if brokers try to rollback to ZK mode > > > during KRaft migration process, there will be a period of time the > > cluster

[VOTE] 3.7.0 RC4

Hello Kafka users, developers and client-developers, This is the second candidate we are considering for release of Apache Kafka 3.7.0. Major changes include: - Early Access to KIP-848 - the next generation of the consumer rebalance protocol - Early Access to KIP-858: Adding JBOD support to KRaft

Re: [VOTE] 3.7.0 RC2

KRaft early access in 3.7.0 is probably the right call. Even without > the bugs we found, there's still quite a few JBOD follow up work to do > (KAFKA-16061) + system tests and documentation updates. > > Thanks, > Mickael > > On Fri, Feb 2, 2024 at 4:49 PM Stanislav Kozlovski

Re: [VOTE] 3.7.0 RC2

On 24 Jan 2024, at 11:51, ka...@gnarula.com wrote: > >>> > >>> Hi Stanislav, > >>> > >>> Thanks for bringing these JIRAs/PRs up. > >>> > >>> I'll be testing the open PRs for KAFKA-14616 and KAFKA-16162 this week > and I h

Re: [VOTE] 3.7.0 RC2

>> > > >>>>> I did not observe any obvious impact. I was able to send and > receive > > >>>>> messages as normally. But to be honest, I have no idea what else > > >>>>> this might impact, so I did not try anything special. >

Re: [VOTE] 3.7.0 RC2

Hi Kirk, Given we are going to have to roll a new RC anyway, and the change is so simple - might as well get it in! On Mon, Jan 15, 2024 at 8:26 PM Kirk True wrote: > Hi Stanislav, > > On Sun, Jan 14, 2024, at 1:17 PM, Stanislav Kozlovski wrote: > > Hey Kirk and Chris, >

Re: [VOTE] 3.7.0 RC2

sers from upgrading. But I leave it to others > > to > > > decide if this is a blocker or not. > > > > > > > Hi Jakub, > > > > Thanks for trying the RC. I think what you found is a blocker bug because > > it will generate huge amount of logspam.

[jira] [Created] (KAFKA-16141) StreamsStandbyTask##test_standby_tasks_rebalanceArguments:{ “metadata_quorum”: “ISOLATED_KRAFT”, “use_new_coordinator”: false} fails consistently in 3.7

Stanislav Kozlovski created KAFKA-16141: --- Summary: StreamsStandbyTask##test_standby_tasks_rebalanceArguments:{ “metadata_quorum”: “ISOLATED_KRAFT”, “use_new_coordinator”: false} fails consistently in 3.7 Key: KAFKA-16141

[jira] [Created] (KAFKA-16140) zookeeper_migration_test#TestMigration#test_recooncile_kraft_to_zk system test fails concistently on 3.7

Stanislav Kozlovski created KAFKA-16140: --- Summary: zookeeper_migration_test#TestMigration#test_recooncile_kraft_to_zk system test fails concistently on 3.7 Key: KAFKA-16140 URL: https://issues.apache.org

[jira] [Created] (KAFKA-16139) StreamsUpgradeTest fails consistently in 3.7.0

Stanislav Kozlovski created KAFKA-16139: --- Summary: StreamsUpgradeTest fails consistently in 3.7.0 Key: KAFKA-16139 URL: https://issues.apache.org/jira/browse/KAFKA-16139 Project: Kafka

[jira] [Created] (KAFKA-16138) QuotaTest system test fails consistently in 3.7

Stanislav Kozlovski created KAFKA-16138: --- Summary: QuotaTest system test fails consistently in 3.7 Key: KAFKA-16138 URL: https://issues.apache.org/jira/browse/KAFKA-16138 Project: Kafka

[jira] [Created] (KAFKA-16136) CoordinatorTest.testTaskRequestWithOldStartMsGetsUpdated() is very flaky

Stanislav Kozlovski created KAFKA-16136: --- Summary: CoordinatorTest.testTaskRequestWithOldStartMsGetsUpdated() is very flaky Key: KAFKA-16136 URL: https://issues.apache.org/jira/browse/KAFKA-16136

[jira] [Created] (KAFKA-16135) kafka.api.PlaintextConsumerTest.testPerPartitionLeadMetricsCleanUpWithSubscribe(String, String).quorum=kraft+kip848.groupProtocol=consumer is flaky

Stanislav Kozlovski created KAFKA-16135: --- Summary: kafka.api.PlaintextConsumerTest.testPerPartitionLeadMetricsCleanUpWithSubscribe(String, String).quorum=kraft+kip848.groupProtocol=consumer is flaky Key: KAFKA-16135

[jira] [Created] (KAFKA-16134) kafka.api.PlaintextConsumerTest.testPerPartitionLagMetricsCleanUpWithSubscribe(String, String).quorum=kraft+kip848.groupProtocol=consumer is flaky

Stanislav Kozlovski created KAFKA-16134: --- Summary: kafka.api.PlaintextConsumerTest.testPerPartitionLagMetricsCleanUpWithSubscribe(String, String).quorum=kraft+kip848.groupProtocol=consumer is flaky Key: KAFKA-16134

Re: [VOTE] 3.7.0 RC2

> I see that this error message is already reported in > > > > > https://issues.apache.org/jira/browse/KAFKA-16029. I think we > should > > > > > prioritize fixing it for this release. I know it's probably benign > > but > > > > it's

[VOTE] 3.7.0 RC2

50f987c0c097f23cb26b4c210c226?context=explore /****** Thanks, Stanislav Kozlovski kafka/test:test (alpine 3.18.5) === Total: 0 (HIGH: 0, CRITICAL: 0)

Re: Apache Kafka 3.7.0 Release

artifacts published > for > >>>> >> > clients. It is only used by the server. > >>>> >> > > >>>> >> > best, > >>>> >> > Colin > >>>> >> > > >>>> >> > > >

Re: Apache Kafka 3.7.0 Release

odule. It is not used by clients. So I > > > don't see why you would want to publish it (unless I'm misunderstanding > > > something). > > > > > > best, > > > Colin > > > > > > > > > On Fri, Jan 5, 2024, at 10:05, Stanislav Ko

Re: Apache Kafka 3.7.0 Release

Thanks for reporting the blockers, folks. Good job finding. I have one ask - can anybody with Gradle expertise help review this small PR? https://github.com/apache/kafka/pull/15127 (+1, -1) In particular, we are wondering whether we need to publish module metadata as part of the gradle publishing

Re: Apache Kafka 3.7.0 Release

; > On Thu, Jan 4, 2024 at 12:49 PM Matthias J. Sax wrote: > > > We found a blocker for 3.7: > > https://issues.apache.org/jira/browse/KAFKA-16077 > > > > Already having a PR under review to fix it. > > > > > > -Matthias > > > > On 1/3/24

[jira] [Resolved] (KAFKA-16046) Stream Stream Joins fail after restoration with deserialization exceptions

[ https://issues.apache.org/jira/browse/KAFKA-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-16046. - Resolution: Fixed > Stream Stream Joins fail after restoration w

Re: Apache Kafka 3.7.0 Release

give you a heads up that > https://github.com/apache/kafka/pull/15073 ( > https://issues.apache.org/jira/browse/KAFKA-16046) was identified as a > blocker regression and should be merged to trunk by EOD. > > Cheers, > Almog > > On Tue, Jan 2, 2024 at 4:20 AM Stanislav Kozl

Re: Apache Kafka 3.7.0 Release

ink about extending the code freeze >> date to >> >> > early January? >> >> > The reason I'm asking is that there are still a couple of testing >> gaps in >> >> > JBOD (https://issues.apache.org/jira/browse/KAFKA-14127) which I &

Re: Apache Kafka 3.7.0 Release

ndly the year end holidays for > many > > > people are coming fast, which means we'll likely have less people > working > > > on testing and validation. In my opinion it would strengthen the > release if > > > we could spend a week in January to really fi

[jira] [Resolved] (KAFKA-12679) Rebalancing a restoring or running task may cause directory livelocking with newly created task

[ https://issues.apache.org/jira/browse/KAFKA-12679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-12679. - Resolution: Fixed Marking this as done as per Lucas' comment that th

[jira] [Resolved] (KAFKA-15147) Measure pending and outstanding Remote Segment operations

[ https://issues.apache.org/jira/browse/KAFKA-15147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-15147. - Resolution: Fixed > Measure pending and outstanding Remote Segment operati

[jira] [Resolved] (KAFKA-15327) Client consumer should commit offsets on close

[ https://issues.apache.org/jira/browse/KAFKA-15327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-15327. - Resolution: Fixed Resolving since this was merged   > Client consumer sho

[jira] [Resolved] (KAFKA-15780) Wait for consistent kraft metadata when creating topics in tests

[ https://issues.apache.org/jira/browse/KAFKA-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-15780. - Resolution: Fixed Resolving since this was merged. Nice work!   > Wait

[jira] [Resolved] (KAFKA-15817) Avoid reconnecting to the same IP address if multiple addresses are available

[ https://issues.apache.org/jira/browse/KAFKA-15817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-15817. - Resolution: Fixed Resolving since this was merged. good job!   > Av

[jira] [Resolved] (KAFKA-16007) ZK migrations can be slow for large clusters

[ https://issues.apache.org/jira/browse/KAFKA-16007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-16007. - Resolution: Fixed Closing since it's merged   > ZK migrations can be

Re: Kafka trunk test & build stability

gt; > org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52) > > >> > > > > at > > >> > > > > > > >> > > > > > >> &

[jira] [Resolved] (KAFKA-15818) Implement max poll interval

[ https://issues.apache.org/jira/browse/KAFKA-15818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-15818. - Resolution: Fixed > Implement max poll inter

[jira] [Resolved] (KAFKA-16026) AsyncConsumer does not send a poll event to the background thread

[ https://issues.apache.org/jira/browse/KAFKA-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-16026. - Resolution: Fixed https://github.com/apache/kafka/pull/15035

Re: [DISCUSS] KIP-975 Docker Image for Apache Kafka

Hey all, As the release manager for 3.7.0, I am pretty interested to know if we should consider this a blocker. Do we have clarity as to whether users could practically rely on this Go script? From a shallow look, it's only used in one line in the Dockerfile. I guess the downside is that images e

Re: Kafka trunk test & build stability

ames=kafka&search.tags=trunk&search.timeZoneId=America%2FNew_York > [3] https://github.com/apache/kafka/pull/15008 > > Thanks for looking into this! > Greg > > On Tue, Dec 19, 2023 at 3:45 PM Николай Ижиков > wrote: > > > > Hello, Stanislav. > >

Kafka trunk test & build stability

Hey everybody, I've heard various complaints that build times in trunk are taking too long, some taking as much as 8 hours (the timeout) - and this is slowing us down from being able to meet the code freeze deadline for 3.7. I took it upon myself to gather up some data in Gradle Enterprise to see

Re: New Release Branch 3.7

ant change pending <https://github.com/apache/kafka/pull/14984>. With that, I remind you that there are only 6 days to code freeze! It's not long until we will have our very first Apache Kafka 3.7 RC! Let's get this shipped. Best, Stanislav On Tue, Dec 12, 2023 at 2:56 PM Stanislav K

Re: Apache Kafka 3.7.0 Release

Hey! Just notifying everybody on this thread that I have cut the 3.7 branch and sent a new email thread titled "New Release Branch 3.7" to the mailing list <https://lists.apache.org/thread/4j87m12fm3bgq01fgphtkfb41s56w6hh>. Best, Stanislav On Wed, Dec 6, 2023 at 11:10 AM Sta

New Release Branch 3.7

Hello Kafka developers and friends, As promised, we now have a release branch for 3.7 release. Trunk is being bumped to 3.8.0-SNAPSHOT (please help review the PR ). I'll be going over the JIRAs to move every non-blocker from this release to the next rel

Re: Apache Kafka 3.7.0 Release

-mail thread titled "New release branch 3.7.0" to notify you, so be on the lookout for that. I will also notify this thread. Thank you for your contributions. Let's get this release shipped! Best, Stanislav On Fri, Nov 24, 2023 at 6:11 PM Stanislav Kozlovski wrote: > Hey all,

Re: Apache Kafka 3.7.0 Release

d and I'm just working on rebasing the implementation against trunk > before I open a PR. > > Regards, > Nick > > On Tue, 21 Nov 2023 at 11:27, Mayank Shekhar Narula < > mayanks.nar...@gmail.com> wrote: > > > Hi Stan > > > > Can you include KIP-951 to

Re: Apache Kafka 3.7.0 Release

smael Juma wrote: > > > > > Thanks Stanislav, +1 > > > > > > Ismael > > > > > > On Thu, Nov 2, 2023 at 7:01 AM Stanislav Kozlovski > > > wrote: > > > > > > > Hi all, > > > > > > > > Given the dis

Re: Apache Kafka 3.7.0 Release

- there are > > often 1-2 day slips and it's better if that doesn't require people > > working through the weekend. > > > > (From this mailing list thread > <https://lists.apache.org/thread/dv1rym2jkf0141sfsbkws8ckkzw7st5h>) > > Thanks for driving the rel

Re: [VOTE] KIP-975: Docker Image for Apache Kafka

Thanks for the KIP! Great idea, well thought out and much needed. +1 (binding) On Fri, 27 Oct 2023 at 06:36, Krishna Agarwal wrote: > Hi, > I'd like to call a vote on KIP-975 which aims to publish an official docker > image for Apache Kafka. > > KIP - > > https://cwiki.apache.org/confluence/dis

Re: Apache Kafka 3.7.0 Release

Jan 3rd, to account for unexpected blockers/delays and time away > during the winter holidays > > Thoughts? > > On Mon, Oct 23, 2023 at 3:14 PM Sophie Blee-Goldman > > wrote: > > > Can you add the 3.7 plan to the release schedule page? > > > > (this -->

Re: Apache Kafka 3.7.0 Release

uster-wide+dynamic+log+adjustment+for+Kafka+Connect > ) > to the release plan? The vote thread for it passed last week and I've > published a complete PR (https://github.com/apache/kafka/pull/14538), so > it > shouldn't be too difficult to get things merged in time for 3.7.

Re: Apache Kafka 3.7.0 Release

7 > >> > >> w: aiven.io > >> > >> e: josep.p...@aiven.io > >> > >> On Mon, Oct 9, 2023, 20:05 Chris Egerton > wrote: > >> > >>> +1, thanks Stanislav! > >>> > >>> On Mon, Oct 9, 2023, 14:02 Bill Bej

[jira] [Resolved] (KAFKA-14175) KRaft Upgrades Part 2

[ https://issues.apache.org/jira/browse/KAFKA-14175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-14175. - Resolution: Won't Fix > KRaft Upgrade

Apache Kafka 3.7.0 Release

Hey all! I would like to volunteer to be the release manager driving the next release - Apache Kafka *3.7.0*. If there are no objections, I will start and share a release plan soon enough! Cheers, Stanislav

Re: [DISCUSS] KIP-932: Queues for Kafka

Hey Andrew! Kudos on the proposal. It is greatly written - a joy to read. It is definitely an interesting solution to the queueing problem - I would not have guessed we could solve it like this. Thank you for working on this. Happy to get the discussion started - I have a few comments/questions o

Re: [VOTE] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

nks, Stan! > > > > On Tue, Aug 23, 2022 at 12:10 PM Luke Chen wrote: > >> > >> Hi Stanislav, > >> > >> Thanks for the KIP. > >> The solution looks reasonable to me. > >> +1 from me. > >> > >> Thank you. > >

Re: [DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

is an important > > use > > > case to address? For example, do we have concrete examples of people > > > running into this? The way the KIP is written, it sounds like a > potential > > > problem but no information is given on whether it's a real proble

[VOTE] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

Hello, I'd like to start a vote on KIP-860, which adds a client-provided option to the AlterPartitionReassignmentsRequest that allows the user to guard against an unintentional change in the replication factor during partition reassignments. Discuss Thread: https://lists.apache.org/thread/bhrqjd4

Re: [DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

der if --disallow-replication-factor-change would be a better > name. I don't feel strong about this so I am happy to go with the > quorum here. > > Best, > David > > On Tue, Aug 16, 2022 at 12:31 AM Stanislav Kozlovski > wrote: > > > > Thanks for the discus

Re: [DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

Thanks for the explanation. I did realize this nuance and thus requested > to > > put that in KIP as it's not mentioned why the choice was made. I am fine > if > > you choose to not do it in the interest of brevity. > > > > Vikas > > > > On Sun, Aug

Re: [DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

e targetReplicaSet size of the new reassignment and throws if those > > differ. > > Can you add more detail to this, or clarify what is targetReplicaSet (for > > e.g. why not sourceReplicaSet?) and how the target replica set will be > > calculated? > > > > And what abo

[DISCISS] KIP-860: Add client-provided option to guard against unintentional replication factor change during partition reassignments

Hey all, I'd like to start a discussion on a proposal to help API users from inadvertently increasing the replication factor of a topic through the alter partition reassignments API. The KIP describes two fairly easy-to-hit race conditions in which this can happen. The KIP itself is pretty simple

[jira] [Created] (KAFKA-14121) AlterPartitionReassignments API should allow callers to specify the option of preserving the replication factor

Stanislav Kozlovski created KAFKA-14121: --- Summary: AlterPartitionReassignments API should allow callers to specify the option of preserving the replication factor Key: KAFKA-14121 URL: https

[jira] [Resolved] (KAFKA-8406) kafka-topics throws wrong error on invalid configuration with bootstrap-server and alter config

[ https://issues.apache.org/jira/browse/KAFKA-8406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-8406. Fix Version/s: 2.4.0 Resolution: Fixed > kafka-topics throws wrong error

Re: [VOTE] KIP-334 Include partitions in exceptions raised during consumer record deserialization/validation

s with > SerDe issues should probably go into a dead-letter queue. > > Anyway, IMO we need exceptions that will let us tell the difference. > > Gwen > > On Fri, Oct 11, 2019 at 10:05 AM Stanislav Kozlovski > wrote: > > > > Thanks Jason. I've edited the K

[jira] [Created] (KAFKA-12555) Log reason for rolling a segment

Stanislav Kozlovski created KAFKA-12555: --- Summary: Log reason for rolling a segment Key: KAFKA-12555 URL: https://issues.apache.org/jira/browse/KAFKA-12555 Project: Kafka Issue Type

[jira] [Created] (KAFKA-10510) Reassigning partitions should not allow increasing RF of a partition unless configured with it

Stanislav Kozlovski created KAFKA-10510: --- Summary: Reassigning partitions should not allow increasing RF of a partition unless configured with it Key: KAFKA-10510 URL: https://issues.apache.org/jira/browse

Re: [ANNOUNCE] Apache Kafka 2.6.0

Sax, > maulin-vasavada, Michael Viamari, Michal T, Mickael Maison, Mitch, Navina > Ramesh, Navinder Pal Singh Brar, nicolasguyomar, Nigel Liang, Nikolay, > Okada Haruki, Paul, Piotr Fras, Radai Rosenblatt, Rajini Sivaram, Randall > Hauch, Rens Groothuijsen, Richard Yu, Rigel Bezerra de Melo,

[jira] [Resolved] (KAFKA-10353) Trogdor - Fix RoundTripWorker to not fail when the topic it's trying to create already exists

[ https://issues.apache.org/jira/browse/KAFKA-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-10353. - Resolution: Duplicate > Trogdor - Fix RoundTripWorker to not fail when

[jira] [Created] (KAFKA-10353) Trogdor - Fix RoundTripWorker to not fail when the topic it's trying to create already exists

Stanislav Kozlovski created KAFKA-10353: --- Summary: Trogdor - Fix RoundTripWorker to not fail when the topic it's trying to create already exists Key: KAFKA-10353 URL: https://issues.apache.org/jira/b

[jira] [Resolved] (KAFKA-10301) Partition#remoteReplicasMap can be empty in certain race conditions

[ https://issues.apache.org/jira/browse/KAFKA-10301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-10301. - Resolution: Fixed > Partition#remoteReplicasMap can be empty in certain r

[jira] [Created] (KAFKA-10302) Ensure thread-safe access to Partition#remoteReplicasMap

Stanislav Kozlovski created KAFKA-10302: --- Summary: Ensure thread-safe access to Partition#remoteReplicasMap Key: KAFKA-10302 URL: https://issues.apache.org/jira/browse/KAFKA-10302 Project: Kafka

[jira] [Created] (KAFKA-10301) RemoteReplicasMap can be empty in certain race conditions

Stanislav Kozlovski created KAFKA-10301: --- Summary: RemoteReplicasMap can be empty in certain race conditions Key: KAFKA-10301 URL: https://issues.apache.org/jira/browse/KAFKA-10301 Project

Re: [VOTE] KIP-627: Expose Trogdor-specific JMX Metrics for Tasks and Agents

+1 (non-binding). Thanks for the work! I am also happy to see Trogdor being improved Best, Stanislav On Fri, Jun 26, 2020 at 5:34 AM Colin McCabe wrote: > +1 (binding). > > Thanks, Sam. > > best, > Colin > > > On Thu, Jun 25, 2020, at 18:05, Gwen Shapira wrote: > > +1 (binding) > > > > Thank y

[jira] [Resolved] (KAFKA-8723) flaky test LeaderElectionCommandTest#testAllTopicPartition

[ https://issues.apache.org/jira/browse/KAFKA-8723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Kozlovski resolved KAFKA-8723. Resolution: Fixed > flaky test LeaderElectionCommandTest#testAllTopicPartit

Re: [DISCUSS] KIP-578: Add configuration to limit number of partitions

g an upper-bound on that number. > > > > > >> > > > > > >> Couple of comments: > > > > > >> > > > > > >> 900. Multi-tenancy - one concern I would have with a cluster and > > >

[jira] [Created] (KAFKA-9866) Do not attempt to elect preferred leader replicas which are outside ISR

Stanislav Kozlovski created KAFKA-9866: -- Summary: Do not attempt to elect preferred leader replicas which are outside ISR Key: KAFKA-9866 URL: https://issues.apache.org/jira/browse/KAFKA-9866

[jira] [Created] (KAFKA-9617) Replica Fetcher can mark partition as failed when max.message.bytes is changed

Stanislav Kozlovski created KAFKA-9617: -- Summary: Replica Fetcher can mark partition as failed when max.message.bytes is changed Key: KAFKA-9617 URL: https://issues.apache.org/jira/browse/KAFKA-9617

[jira] [Created] (KAFKA-9589) LogValidatorTest#testLogAppendTimeNonCompressedV2 is not executed and does not pass

Stanislav Kozlovski created KAFKA-9589: -- Summary: LogValidatorTest#testLogAppendTimeNonCompressedV2 is not executed and does not pass Key: KAFKA-9589 URL: https://issues.apache.org/jira/browse/KAFKA-9589

Re: [ANNOUNCE] New Kafka PMC Members: Colin, Vahid and Manikumar

Congratulations to all! Best, Stanislav On Tue, Jan 14, 2020 at 9:30 AM Gwen Shapira wrote: > Hi everyone, > > I'm happy to announce that Colin McCabe, Vahid Hashemian and Manikumar > Reddy are now members of Apache Kafka PMC. > > Colin and Manikumar became committers on Sept 2018 and Vahid on

Re: [VOTE] KIP-526: Reduce Producer Metadata Lookups for Large Number of Topics

+1 (non-binding) Thanks for the KIP, Brian! On Thu, Jan 2, 2020 at 7:15 PM Brian Byrne wrote: > Hello all, > > After further discussion and improvements, I'd like to reinstate the voting > process. > > The updated KIP: https://cwiki.apache.org/confluence/display/KAFKA/KIP-526 > %3A+Reduce+Produ

  1   2   3   4   >