Re: [DISCUSS] KIP-597: MirrorMaker2 internal topics Formatters

Thanks Chris for the feedback. 1. I've added sample output for the 3 formatters 2. Good idea, instead of deleting the existing trait, let's mark it as deprecated and make it extend the new interface. I've updated to the KIP. I've also opened a draft PR: https://github.com/apache/kafka/pull/8604

Re: Permission to create a KIP

Hello Aakash, I've added you to the wiki space. Cheers, Guozhang On Sat, May 2, 2020 at 10:12 PM Aakash Shah wrote: > Hello, > > I would like to request permission to create a KIP. > > My Wiki ID is aakash33 and my email is as...@confluent.io. > > Thank you! > > Best, > > Aakash Shah > -- -

Re: [VOTE] KIP-441: Smooth Scaling Out for Kafka Streams

Hi Matthias, We originally proposed that config to allow us to skip migrating tasks if the current balance is “good enough”. But during implementation, we became concerned that supporting this option increased code complexity, and it’s also an extra concept for users to have to learn. To keep

Re: [DISCUSS] KIP-597: MirrorMaker2 internal topics Formatters

Hi Mickael, Thanks! This looks great, +1 non-binding. Cheers, Chris On Sun, May 3, 2020 at 4:13 AM Mickael Maison wrote: > Thanks Chris for the feedback. > > 1. I've added sample output for the 3 formatters > 2. Good idea, instead of deleting the existing trait, let's mark it as > deprecated

Re: [Discuss] KIP-582 Add a "continue" option for Kafka Connect error handling

Hi Zihan, I guess I'm still unclear on exactly what form this analysis might take. If a converter has an issue (de)-serializing a record, for example, the first thing I check out is the stack trace in the worker logs that tells me what went wrong and where. The same goes for errors thrown during t

Re: [DISCUSS] KIP-605 Expand Connect Worker Internal Topic Settings

Hi Randall, Thanks for the KIP! I have a few questions and suggestions but no major objections. 1. The motivation is pretty clear for altering the various "*.storage.replication.factor" properties to allow -1 as a value now. Are there expected use cases for allowing modification of other properti

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

Thanks Stanislav. Apologies about the long absence from this thread. I would prefer having per-user max partition limits in a separate KIP. I don't see this as an MVP for this KIP. I will add this as an alternative approach into the KIP. I was in a double mind about whether or not to impose the p

Re: [DISCUSSION] KIP-418: A method-chaining way to branch KStream

Hello everyone, will someone please take a look at the reworked KIP? I believe that now it follows design principles and takes into account all the arguments discussed here. Regards, Ivan 23.04.2020 2:45, Ivan Ponomarev пишет: Hi, I have read the John's "DSL design principles" and have

Build failed in Jenkins: kafka-trunk-jdk8 #4496

See Changes: [cshapi] MINOR: Annotate KafkaAdminClientTest.testAlterClientQuotas() with @Test -- [...truncated 3.06 MB...] org.apache.kafka.streams.TopologyTestDriverTest

Build failed in Jenkins: kafka-trunk-jdk11 #1421

See Changes: [cshapi] MINOR: Annotate KafkaAdminClientTest.testAlterClientQuotas() with @Test -- [...truncated 3.08 MB...] org.apache.kafka.streams.TestTopicsTest > test

Re: [VOTE] KIP-441: Smooth Scaling Out for Kafka Streams

Hello John / Sophie: With this config removed, would the assignor always tries to to achieve the "perfect balance" (of course, it may be a sub-optimal local plateau) or there's an internal hard-coded factor to still retain some satisfying threshold? Guozhang On Sun, May 3, 2020 at 9:23 AM John R

Re: [DISCUSS] KIP-598: Augment TopologyDescription with store and source / sink serde information

Hello Matthias John, thanks for your comments!! Replied them inline. I think there are a couple open questions that I'd like to hear your opinions on with the context: a. For stores's serdes, the reason I proposed to expose a set of serde names instead of a pair of key / value serdes is for futur

Re: [DISCUSS] KIP-554: Add Broker-side SCRAM Config API

Hello Colin, Thanks for the KIP. The proposal itself looks good to me; but could you elaborate a bit more on the rejected alternative of reusing IncrementalAlterConfigs? What do you mean by complex string manipulation, as well as error conditions? Guozhang On Fri, May 1, 2020 at 5:12 PM Colin M

Re: [DISCUSS] KIP-595: A Raft Protocol for the Metadata Quorum

Hello Jun, Thanks for your comments! I'm replying inline below: On Fri, May 1, 2020 at 12:36 PM Jun Rao wrote: > Hi, Jason, > > Thanks for the KIP. Great writeup. A few comments below. > > 100. Do we need AlterQuorum in the first version? Quorum changes are rare > and the implementation is invo

Re: [VOTE] KIP-441: Smooth Scaling Out for Kafka Streams

Hi Guozhang, Ah, good question. Yes, the assignor will always now try to achieve a perfect balance. This was also the proposed default in the KIP before. The config would have allowed users to relax the search for perfection. This is actually one of our motivations now to remove it. We feel it’

Re: [Discuss] KIP-581: Value of optional null field which has default value

Hi Cheng, I think refactoring that method should be fine (if maybe a little painful); the method itself is private and all places that it's invoked directly are either package-private or non-static, so it shouldn't affect any of the public methods of the JSON converter to change "convertToConnect"

[jira] [Created] (KAFKA-9949) Flaky Test GlobalKTableIntegrationTest#shouldKStreamGlobalKTableLeftJoin

Matthias J. Sax created KAFKA-9949: -- Summary: Flaky Test GlobalKTableIntegrationTest#shouldKStreamGlobalKTableLeftJoin Key: KAFKA-9949 URL: https://issues.apache.org/jira/browse/KAFKA-9949 Project: K

Re: [DISCUSS] KIP-585: Conditional SMT

Hi all, This has certainly taken quite a turn! I wish we could get this done without adding another pluggable interface but if the benefit is that now any SMT--new or pre-existing--can be conditionally applied, it seems like it might be worth it. As far as the proposed design goes, some thoughts:

[jira] [Created] (KAFKA-9950) MirrorMaker2 sharing of ConfigDef can lead to ConcurrentModificationException

Chris Egerton created KAFKA-9950: Summary: MirrorMaker2 sharing of ConfigDef can lead to ConcurrentModificationException Key: KAFKA-9950 URL: https://issues.apache.org/jira/browse/KAFKA-9950 Project: