Build failed in Jenkins: Kafka » kafka-trunk-jdk15 #671

See Changes: [github] KAFKA-12537: fix application shutdown corner case with only one thread (#10387) -- [...truncated 3.68 MB...]

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

It does mean more than that. We don't remove or replace things in Apache Kafka without good reasons (since it's typically costly for users). And once something is scheduled for removal, it's typically in maintenance mode and only bug fixes are expected. Ismael On Fri, Mar 26, 2021, 8:28 PM

[jira] [Resolved] (KAFKA-12537) Single Threaded EOS applications will not work with SHUTDOWN_APPLICATION

[ https://issues.apache.org/jira/browse/KAFKA-12537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12537. Fix Version/s: 2.8.0 Resolution: Fixed > Single Threaded EOS

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Ismael, "deprecated" implies something is scheduled to be removed or replaced, but I don't think it implies anything more than that. KIP-720 is proposing to deprecate MM1 so it can eventually be removed. That's all this particular KIP is proposing. Ryanne On Fri, Mar 26, 2021, 7:24 PM Ismael

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Thanks Tom, this is a good elaboration on what I meant. Also, if it's deprecated, then we should definitely not be adding features. I'm a puzzled that we are saying that MM1 is useful, deserves additional development and should be deprecated - all at the same time. Ismael On Fri, Mar 26, 2021,

[jira] [Created] (KAFKA-12565) Global thread only topologies should be able to shutdown applications via the uncaught exception handler

Walker Carlson created KAFKA-12565: -- Summary: Global thread only topologies should be able to shutdown applications via the uncaught exception handler Key: KAFKA-12565 URL:

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

The timing is unfortunate, but should not be a roadblock. Both KIPs are already worded to leave room for the other. I think this is a non-issue. On Fri, Mar 26, 2021 at 2:49 PM Ning Zhang wrote: > IMHO - I think there is no too much doubt on the effectiveness of KIP-712 > and KIP-720, the

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

IMHO - I think there is no too much doubt on the effectiveness of KIP-712 and KIP-720, the tricky part may be the timing and the ordering of implementing KIP-712 and KIP-720 (if we do not want to execute both KIP in parallel). If it makes more sense to execute them in sequence, here may be a

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

Thanks for the KIP! I'm 100% on board with this (obviously :P) and the KIP itself looks good to me overall. Just one clarification I think you should make: In the *Public Interfaces* section you say "It won't affect the current consumers" -- this is only true if those current consumers have

Re: [DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Just noticed you started up a new DISCUSS thread for this KIP with the updated KIP number -- I'll copy my response over to the latest thread. On Fri, Mar 26, 2021 at 12:22 PM Sophie Blee-Goldman wrote: > Thanks for the KIP! I'm 100% on board with this (obviously :P) and the KIP > itself looks

[jira] [Resolved] (KAFKA-10396) Overall memory of container keep on growing due to kafka stream / rocksdb and OOM killed once limit reached

[ https://issues.apache.org/jira/browse/KAFKA-10396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-10396. Resolution: Fixed > Overall memory of container keep on growing due to

Re: [DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Thanks for the KIP! I'm 100% on board with this (obviously :P) and the KIP itself looks good to me overall. Just one clarification I think you should make: In the *Public Interfaces* section you say "It won't affect the current consumers" -- this is only true if those current consumers have

Re: [DISCUSS] KIP-712: Shallow Mirroring

> so as to avoid creating a perverse incentive for users to not adopt MM2? Tom, I know there are several of us chomping at the bit to enable this in MM2, so I don't think that's a problem. AFAICT there won't be a separate KIP required -- we just need to enable this new option in MM2 by default.

Re: [DISCUSS] KIP-712: Shallow Mirroring

Hi, Thanks for the KIP. I've not yet read it in detail, so have no technical points to make at this point. I'm having trouble reconciling KIP-720's deprecation of MM1 with this proposal to add a new feature to MM1 and not to MM2. I think this would create a confusing impression to users. Given

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Hi Ryanne, Thanks for the clarification. I agree that inertia is not a good enough reason to keep MM1 around. It is a bit weird to be deprecating MM1 in one KIP but proposing to develop it further in another, and that development, if it happened, would undermine the argument that MM2 does

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Tom, to clarify, MM2 can definitely replace MM1 in all use cases I've encountered or can imagine, and many orgs have switched already, e.g. using IdentityReplicationPolicy aka LegacyReplicationPolicy. Moreover, the argument of whether to extend or replace MM1 was already decided in KIP-382. That

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Hi Ryanne, With respect, there's a difference between "we still use it because we can't be bothered to switch to MM2, or just haven't yet" and "it's important for xyz because MM2 doesn't serve our use case properly". While the former is not a good reason to argue against deprecation, the latter

Jenkins build is back to normal : Kafka » kafka-2.7-jdk8 #140

See

[jira] [Resolved] (KAFKA-12563) Something wrong with MM2 metrics

[ https://issues.apache.org/jira/browse/KAFKA-12563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bui Thanh MInh resolved KAFKA-12563. Resolution: Resolved > Something wrong with MM2 metrics >

Re: [VOTE] KIP-720 Deprecate MirrorMaker v1

Ismael, I think it is very difficult in general to argue for deprecation -- someone will always say "we still use it" or "it's important for xyz" -- so I don't want to make claims that prompt such responses. The motivation for deprecating MM1 is that we now have MM2, and there isn't much else to

Re: [DISCUSS] KIP-690 Add additional configuration to control MirrorMaker 2 internal topics naming convention

Omnia, have we considered just adding methods to ReplicationPolicy? I'm reluctant to add a new class because, as Mickael points out, we'd need to carry it around in client code. Ryanne On Fri, Feb 19, 2021 at 8:31 AM Mickael Maison wrote: > Hi Omnia, > > Thanks for the clarifications. > > -

[VOTE] 2.7.1 RC1

Hello Kafka users, developers and client-developers, This is the second candidate for release of Apache Kafka 2.7.1. Since 2.7.1 RC0, the following JIRAs have been fixed: KAFKA-12508 Release notes for the 2.7.1 release: https://home.apache.org/~mimaison/kafka-2.7.1-rc1/RELEASE_NOTES.html ***

Broker-level min ISR for __consumer_offsets

Hi, Community, I wanted to reach out about the following scenario. It was most likely discussed before and a long time ago: I apologise in advance for the repeat. I am customising broker-level replication settings of an internal topic (in this case, the consumer offsets topic) to accommodate the

Re: [DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Thank you ! Sagar. On Fri, 26 Mar 2021 at 2:21 PM, Luke Chen wrote: > Hi Sagar, > No problem. I changed my KIP to KIP-726, and also added your KIP into the > KIP list table. > > I'll send another discussion mail later for KIP-726. > > Thanks > Luke > > On Fri, Mar 26, 2021 at 4:41 PM Sagar

Build failed in Jenkins: Kafka » kafka-trunk-jdk15 #670

See Changes: [github] MINOR: Use Java 11 for generating aggregated javadoc in release.py (#10399) -- [...truncated 7.39 MB...] TransactionsTest >

[DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

Hi everyone, I'd like to discuss the following proposal to make the CooperativeStickyAssignor as the default assignor. https://cwiki.apache.org/confluence/display/KAFKA/KIP-726%3A+Make+the+CooperativeStickyAssignor+as+the+default+assignor Any comments are welcomed. Thank you. Luke

KIP-726: Make the CooperativeStickyAssignor as the default assignor

Hi everyone, I'd like to discuss the following proposal to make the CooperativeStickyAssignor as the default assignor. https://cwiki.apache.org/confluence/display/KAFKA/KIP-726%3A+Make+the+CooperativeStickyAssignor+as+the+default+assignor Any comments are welcomed. Thank you. Luke

Re: [DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Hi Sagar, No problem. I changed my KIP to KIP-726, and also added your KIP into the KIP list table. I'll send another discussion mail later for KIP-726. Thanks Luke On Fri, Mar 26, 2021 at 4:41 PM Sagar wrote: > Hey Luke, > > There's a conflict in the KIP numbers. I have also used 725 for the

[jira] [Created] (KAFKA-12564) KTable#filter-method called twice after aggregation

Jessica Johann created KAFKA-12564: -- Summary: KTable#filter-method called twice after aggregation Key: KAFKA-12564 URL: https://issues.apache.org/jira/browse/KAFKA-12564 Project: Kafka

Re: [DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Hey Luke, There's a conflict in the KIP numbers. I have also used 725 for the KiP I had written last week; https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=177047930. I had incremented the number while creating this but forgot to add it here. Do you want me to change the KIP

Re: [DISCUSS] KIP-725: Streamlining configurations for TimeWindowedDeserializer.

Hi Sophie, Thanks for the feedback! I have updated the KIP inline with whatever you suggested. Regarding point 5, I have added the note as it makes sense to not set the config via the KafkaStreams app. Thanks! Sagar. On Wed, Mar 24, 2021 at 7:52 AM Sophie Blee-Goldman wrote: > Hey Sagar, >

[DISCUSS] KIP-725: Make the CooperativeStickyAssignor as the default assignor

Hi everyone, I'd like to discuss the following proposal to make the CooperativeStickyAssignor as the default assignor. https://cwiki.apache.org/confluence/display/KAFKA/KIP-725%3A+Make+the+CooperativeStickyAssignor+as+the+default+assignor Any comments are welcomed. Thank you. Luke

Jenkins build is back to normal : Kafka » kafka-2.8-jdk8 #81

See

Re: [VOTE] KIP-712: Shallow Mirroring

+1 from me. Will be very beneficial and efficient to the users who mirroring at large scale. On 2021/03/25 17:33:53, Henry Cai wrote: > Hi, > > > I'd like to start a vote on KIP-712: Shallow Mirroring. > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-712%3A+Shallow+Mirroring >