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

See Changes: [github] KAFKA-10010: Should make state store registration idempotent (#8681) -- [...truncated 1.08 MB...]

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

See Changes: [github] KAFKA-10011: Remove task id from lockedTaskDirectories during -- [...truncated 4.99 MB...] kafka.controller.ReplicaStateMachineTest >

Re: [VOTE] KIP-613: Add end-to-end latency metrics to Streams

We can conclude the vote on this: the KIP passes with three +1 (binding) votes from Guzhang, Bill, and John. Thanks all for the great discussion and feedback! On Tue, May 19, 2020 at 3:34 PM Bill Bejeck wrote: > Thanks for the KIP, I'm a +1 (binding) on the proposal. > > -Bill > > On Tue, May

Re: [VOTE] KIP-601: Configurable socket connection timeout in NetworkClient

Dear Colin, Thanks for the reply. Your reasoning make sense. I’ve modified the KIP-601 with two changes: 1. Now KIP-601 is proposing a exponential connection setup timeout, which is controlled by socket.connections.setup.timeout.ms (init value) and socket.connections.setup.timeout.max.ms

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

See Changes: [github] KAFKA-10011: Remove task id from lockedTaskDirectories during [github] KAFKA-10010: Should make state store registration idempotent (#8681) --

Re: [DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

Thanks for the response, Sophie, I wholeheartedly agree we should take as much into account as possible up front, rather than regretting our decisions later. I actually do share your vague sense of worry, which was what led me to say initially that I thought my counterproposal might be "too

Build failed in Jenkins: kafka-trunk-jdk14 #106

See Changes: [github] KAFKA-10010: Should make state store registration idempotent (#8681) -- [...truncated 3.09 MB...] org.apache.kafka.streams.TopologyTestDriverTest >

Re: [DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

> Rather than working around it, I think we should just fix it Now *that's* a "fancy" idea :P That was my primary concern, although I do have a vague sense of worry that we might be allowing users to get into trouble without realizing it. For example if their custom serdes suffer a similar bug

Jenkins build is back to normal : kafka-2.5-jdk8 #126

See

Re: [DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

Thanks Sophie, Woah, that’s a nasty bug. Rather than working around it, I think we should just fix it. I’ll leave some comments on the Jira. It doesn’t seem like it should be this KIP’s concern that some serdes might be incorrectly written. Were there other practical concerns that you had in

Re: [VOTE]: KIP-604: Remove ZooKeeper Flags from the Administrative Tools

On Tue, May 19, 2020, at 09:31, Jason Gustafson wrote: > Hi Colin, > > Looks good. I just had one question. It sounds like your intent is to > change kafka-configs.sh so that the --zookeeper flag is only supported for > bootstrapping. I assume in the case of SCRAM that we will only make this >

Re: [DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

I like this "fancy idea" to just flip the to/from bytes but I think there are some practical limitations to implementing this. In particular I'm thinking about this issue with the built-in signed number serdes. This trick would actually fix the

Build failed in Jenkins: kafka-trunk-jdk14 #105

See Changes: [github] KAFKA-10011: Remove task id from lockedTaskDirectories during -- [...truncated 3.09 MB...] org.apache.kafka.streams.TopologyTestDriverTest >

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

See Changes: [github] KAFKA-6145: Add unit tests to verify fix of bug KAFKA-9173 (#8689) [github] KAFKA-9992: Eliminate JavaConverters in EmbeddedKafkaCluster (#8673)

Re: [VOTE] KIP-613: Add end-to-end latency metrics to Streams

Thanks for the KIP, I'm a +1 (binding) on the proposal. -Bill On Tue, May 19, 2020 at 3:02 PM Guozhang Wang wrote: > +1 on the updated proposal. Thanks Sophie. > > On Tue, May 19, 2020 at 11:51 AM John Roesler wrote: > > > Thanks for the KIP, Sophie. > > > > I'm +1 (binding) on the current

Re: [DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

Hi there Jorge, Thanks for the KIP! I think this feature sounds very reasonable. I'm not 100% sure if this is "too fancy", but what do you think about avoiding the enum by instead allowing people to flip the "from" and "to" endpoints? I.e., reading from "A" to "Z" would be a forward scan, and

Build failed in Jenkins: kafka-trunk-jdk14 #104

See Changes: [github] KAFKA-6145: Add unit tests to verify fix of bug KAFKA-9173 (#8689) [github] KAFKA-9992: Eliminate JavaConverters in EmbeddedKafkaCluster (#8673)

[jira] [Resolved] (KAFKA-9982) [kafka-connect] Source connector does not guarantee at least once delivery

[ https://issues.apache.org/jira/browse/KAFKA-9982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Egerton resolved KAFKA-9982. -- Resolution: Not A Bug > [kafka-connect] Source connector does not guarantee at least once

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hello all, I'd actually like to retract the earlier additions to the KIP and point out that since I've started the voting process and gotten some responses, I will not be making any major changes to the KIP as it would require a re-voting process. Thanks, Aakash On Tue, May 19, 2020 at 2:31 PM

Re: [VOTE] KIP-610: Error Reporting in Sink Connectors

+1 (binding) I like how the KIP looks now too. Quite active discussions within the past few days, which I found very useful. There's some room to allow in the future the connector developers to decide whether they want greater control over error reporting or they want the framework to keep

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Chris and others, Yes, you are correct; I looked through KIP-298 to understand it better. I agree with your idea to handle "errors.tolerance=none." I see, you are basically saying you are in favor of standardizing handling what to set the reporter to if it is not configured. I am on board

Re: [VOTE] KIP-610: Error Reporting in Sink Connectors

+1 (binding) This will be a nice improvement. From the discussion thread it's clear this is tricky to get right, nice work! On Tue, May 19, 2020 at 8:16 AM Andrew Schofield wrote: > +1 (non-binding) > > This is now looking very nice. > > Andrew Schofield > > On 19/05/2020, 16:11, "Randall

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

See Changes: [github] KAFKA-6145: Add unit tests to verify fix of bug KAFKA-9173 (#8689) [github] KAFKA-9992: Eliminate JavaConverters in EmbeddedKafkaCluster (#8673)

[DISCUSS] KIP-617: Allow Kafka Streams State Stores to be iterated backwards

Hi everyone, I would like to start the discussion for KIP-617: https://cwiki.apache.org/confluence/display/KAFKA/KIP-617%3A+Allow+Kafka+Streams+State+Stores+to+be+iterated+backwards Looking forward to your feedback. Thanks! Jorge. 0x5F2C6E22064982DF.asc Description: application/pgp-keys

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Aakash, > If "errors.tolerance=none", should it not be the case that the error reporter does not even report any error; rather, the task just fails after throwing the error? I do understand the point you are saying about duplicates, though. I believe the "errors.tolerance" property dictates

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Arjun, I am not very familiar with how the potential heartbeat failure would cause more failures when consuming subsequent records. Can you elaborate on this? Thanks, Aakash On Tue, May 19, 2020 at 10:03 AM Arjun Satish wrote: > One more concern with the connector blocking on the Future's

Re: [DISCUSS] KIP-601: Configurable socket connection timeout

On Tue, May 19, 2020, at 03:27, Rajini Sivaram wrote: > Hi Colin, > > I do agree about the `leastLoadedNode` case. My question was about the > other cases where we are connecting to a specific node: fetch requests to > leaders, produce requests to leaders, requests to group coordinators, >

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Chris, Thanks for the suggestions. If "errors.tolerance=none", should it not be the case that the error reporter does not even report any error; rather, the task just fails after throwing the error? I do understand the point you are saying about duplicates, though. You raise a good point

Re: [VOTE] KIP 585: Filter and conditional SMTs

Thanks for the KIP Tom, this will be a useful addition. +1(binding) -Bill On Tue, May 19, 2020 at 1:14 PM Tom Bentley wrote: > It would be nice to get this into Kafka 2.6. There are 2 binding and 3 > non-binding votes so far. If you've not looked at it already now would be a > great time! > >

Re: [VOTE] KIP-221: Enhance KStream with Connecting Topic Creation and Repartition Hint

While working on the follow up PR to deprecate `through()`, I realized that we forgot to add `repartition()` to the Scala API. I updated the KIP accordingly and my PR also include the update to the Scala API (for adding `repartition()` and deprecating `through()`):

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

We already has a Serdes actually, which is a factory class. What we really need is to add new functions to `Serde`, `Serializer` and `Deserializer` interfaces, but since we already dropped Java7 backward compatibility may not be a big issue anyways, let me think about it a bit more. On Tue, May

Build failed in Jenkins: kafka-trunk-jdk14 #103

See Changes: [github] MINOR: Update stream documentation (#8622) -- [...truncated 3.09 MB...] org.apache.kafka.streams.test.OutputVerifierTest >

Re: [DISCUSS] KIP-589 Add API to Update Replica State in Controller

Thanks, Jason. Good feedback 1. I was mostly referring to the fact that the ReplicaManager uses a background thread to send the ZK notification and it really has no visibility as to whether the ZK operation succeeded or not. We'll most likely want to continue using a background thread for

Re: [DISCUSS] KIP-573: Enable TLSv1.3 by default

PR - https://github.com/apache/kafka/pull/8695 > 18 мая 2020 г., в 23:30, Nikolay Izhikov написал(а): > > Hello, Colin > > We need hack only because TLSv1.3 not supported in java8. > >> Java 8 will receive TLS 1.3 support later this year >> (https://java.com/en/jre-jdk-cryptoroadmap.html) >

Jenkins build is back to normal : kafka-trunk-jdk8 #4543

See

Re: [VOTE] KIP-613: Add end-to-end latency metrics to Streams

+1 on the updated proposal. Thanks Sophie. On Tue, May 19, 2020 at 11:51 AM John Roesler wrote: > Thanks for the KIP, Sophie. > > I'm +1 (binding) on the current proposal. > > Thanks, > -John > > On Fri, May 15, 2020, at 19:45, Guozhang Wang wrote: > > Hi Sophie, > > > > Sorry I was a bit late

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

Thanks Guozhang. This makes sense. I am still wondering about wrapped serdes: > and if it is a wrapper serde, also print its inner >>> serde name How can our default implementation of `TopologyDescriber` know if it's a wrapped serde or not? Furthermore, how do wrapped serdes expose their inner

Re: [DISCUSS] KIP-589 Add API to Update Replica State in Controller

Hi David, This looks good. I just have a few comments: 1. I'm not sure it's totally fair to describe the current notification mechanism as "best-effort." At least it guarantees that the controller will eventually see the event. In any case, I think we might want a stronger contract going

Re: [VOTE] KIP-613: Add end-to-end latency metrics to Streams

Thanks for the KIP, Sophie. I'm +1 (binding) on the current proposal. Thanks, -John On Fri, May 15, 2020, at 19:45, Guozhang Wang wrote: > Hi Sophie, > > Sorry I was a bit late on following up the DISCUSS thread. I still have > some comment about the processor-node level metrics and left a

Re: Granting permission for Create KIP

Done. On 5/19/20 7:10 AM, 阮良 wrote: > Please grant permission for Create KIP to wiki ID: ruanliang_hualun > signature.asc Description: OpenPGP digital signature

Build failed in Jenkins: kafka-trunk-jdk14 #102

See Changes: [github] MINOR: Small fixes in the documentation (#8623) -- [...truncated 6.18 MB...] org.apache.kafka.streams.TopologyTestDriverTest >

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Randall, First off, thank you for the incredibly detailed example. I don't mind walls of text. I found it very helpful. I especially liked the idea about modifying how the framework invokes "SinkTask::preCommit" to take most of the work out of developers' hands in the common case of a

Re: [DISCUSS] KIP-609: Use Pre-registration and Blocking Calls for Better Transaction Efficiency

Hey John, thanks for the insights! Replied inline. On Tue, May 19, 2020 at 7:48 AM John Roesler wrote: > Thanks for the KIP, Boyang! > > This looks good and reasonable to me overall. > > J1: One clarification: you mention that the blocking behavior depends on > a new broker version, which

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

See Changes: [github] MINOR: Small fixes in the documentation (#8623) [github] MINOR: Update stream documentation (#8622) -- [...truncated 3.09 MB...]

Re: [VOTE] KIP 585: Filter and conditional SMTs

It would be nice to get this into Kafka 2.6. There are 2 binding and 3 non-binding votes so far. If you've not looked at it already now would be a great time! Many thanks, Tom On Tue, May 19, 2020 at 1:27 PM Mickael Maison wrote: > +1 (binding) > Thanks Tom for leading this KIP and steering

[jira] [Created] (KAFKA-10025) Segfault in RocksDB Statistics

Sophie Blee-Goldman created KAFKA-10025: --- Summary: Segfault in RocksDB Statistics Key: KAFKA-10025 URL: https://issues.apache.org/jira/browse/KAFKA-10025 Project: Kafka Issue Type: Bug

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

One more concern with the connector blocking on the Future's get() is that it may cause the task's consumer to fail to heartbeat (since there is no independent thread to do this). That would then cause failures when we eventually try to consume more records after returning from put(). The

[jira] [Created] (KAFKA-10024) Add dynamic configuration and enforce quota for per-IP connection rate limits

Anna Povzner created KAFKA-10024: Summary: Add dynamic configuration and enforce quota for per-IP connection rate limits Key: KAFKA-10024 URL: https://issues.apache.org/jira/browse/KAFKA-10024

Re: [VOTE]: KIP-604: Remove ZooKeeper Flags from the Administrative Tools

Hi Colin, Looks good. I just had one question. It sounds like your intent is to change kafka-configs.sh so that the --zookeeper flag is only supported for bootstrapping. I assume in the case of SCRAM that we will only make this change after the broker API is available? Thanks, Jason On Tue, May

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Can we get a couple of examples that shows utility of waiting on the Future<>? Also, in preCommit() we would report back on the incomplete offsets. So that feedback mechanism will already exists for developers who want to manually manage this. On Tue, May 19, 2020 at 8:03 AM Randall Hauch wrote:

[jira] [Created] (KAFKA-10023) Enforce broker-wide and per-listener connection creation rate (KIP-612, part 1)

Anna Povzner created KAFKA-10023: Summary: Enforce broker-wide and per-listener connection creation rate (KIP-612, part 1) Key: KAFKA-10023 URL: https://issues.apache.org/jira/browse/KAFKA-10023

[GitHub] [kafka-site] bbejeck commented on pull request #265: MINOR: Update stream documentation for version 2.5

bbejeck commented on pull request #265: URL: https://github.com/apache/kafka-site/pull/265#issuecomment-630893259 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub

[GitHub] [kafka-site] bbejeck merged pull request #265: MINOR: Update stream documentation for version 2.5

bbejeck merged pull request #265: URL: https://github.com/apache/kafka-site/pull/265 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go

Re: [VOTE] KIP-610: Error Reporting in Sink Connectors

+1 (non-binding) This is now looking very nice. Andrew Schofield On 19/05/2020, 16:11, "Randall Hauch" wrote: Thank you, Aakash, for putting together this KIP and shepherding the discussion. Also, many thanks to all those that participated in the very active discussion. I'm

Re: [VOTE] KIP-610: Error Reporting in Sink Connectors

Thank you, Aakash, for putting together this KIP and shepherding the discussion. Also, many thanks to all those that participated in the very active discussion. I'm actually very happy with the current proposal, am confident that it is a valuable improvement to the Connect framework, and know that

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Thanks, Aakash, for updating the KIP. On Tue, May 19, 2020 at 2:18 AM Arjun Satish wrote: > Hi Randall, > > Thanks for the explanation! Excellent point about guaranteeing offsets in > the async case. > > If we can guarantee that the offsets will be advanced only after the bad > records are

Re: [DISCUSS] KIP-609: Use Pre-registration and Blocking Calls for Better Transaction Efficiency

Thanks for the KIP, Boyang! This looks good and reasonable to me overall. J1: One clarification: you mention that the blocking behavior depends on a new broker version, which sounds good to me, but I didn't see why we would need to throw any UnsupportedVersionExceptions. It sounds a little like

Granting permission for Create KIP

Please grant permission for Create KIP to wiki ID: ruanliang_hualun

[jira] [Created] (KAFKA-10022) console-producer suppert set client.id

Young Chou created KAFKA-10022: -- Summary: console-producer suppert set client.id Key: KAFKA-10022 URL: https://issues.apache.org/jira/browse/KAFKA-10022 Project: Kafka Issue Type: Improvement

Re: [VOTE]: KIP-604: Remove ZooKeeper Flags from the Administrative Tools

+1 (binding) Thanks Colin On Tue, May 19, 2020 at 10:57 AM Manikumar wrote: > > +1 (binding) > > Thanks for the KIP > > On Tue, May 19, 2020 at 12:29 PM David Jacot wrote: > > > +1 (non-binding). > > > > Thanks for the KIP. > > > > On Fri, May 15, 2020 at 12:41 AM Guozhang Wang wrote: > > > >

Re: [VOTE] KIP 585: Filter and conditional SMTs

+1 (binding) Thanks Tom for leading this KIP and steering the syntax discussion towards a consensus On Tue, May 19, 2020 at 11:29 AM Edoardo Comar wrote: > > +1 (non-binding) > Thanks Tom > -- > > Edoardo Comar > > Event Streams for IBM Cloud > IBM

[jira] [Resolved] (KAFKA-6690) Priorities for Source Topics

[ https://issues.apache.org/jira/browse/KAFKA-6690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Afshartous resolved KAFKA-6690. Resolution: Won't Fix > Priorities for Source Topics > > >

RE: [VOTE] KIP 585: Filter and conditional SMTs

+1 (non-binding) Thanks Tom -- Edoardo Comar Event Streams for IBM Cloud IBM UK Ltd, Hursley Park, SO21 2JN From: Gunnar Morling To: dev@kafka.apache.org Date: 19/05/2020 10:35 Subject:[EXTERNAL] Re: [VOTE] KIP 585: Filter and

Re: [DISCUSS] KIP-601: Configurable socket connection timeout

Hi Colin, I do agree about the `leastLoadedNode` case. My question was about the other cases where we are connecting to a specific node: fetch requests to leaders, produce requests to leaders, requests to group coordinators, requests to controller etc. It will be good to either quantify that

Re: [DISCUSS] KIP-405: Kafka Tiered Storage

Hi Jun, Please go through the wiki which has the latest updates. Google doc is updated frequently to be in sync with wiki. Thanks, Satish. On Tue, May 19, 2020 at 12:30 AM Jun Rao wrote: > Hi, Satish, > > Thanks for the update. Just to clarify. Which doc has the latest updates, > the wiki or

Re: [VOTE]: KIP-604: Remove ZooKeeper Flags from the Administrative Tools

+1 (binding) Thanks for the KIP On Tue, May 19, 2020 at 12:29 PM David Jacot wrote: > +1 (non-binding). > > Thanks for the KIP. > > On Fri, May 15, 2020 at 12:41 AM Guozhang Wang wrote: > > > +1. > > > > Thanks Colin! > > > > Guozhang > > > > On Tue, May 12, 2020 at 3:45 PM Colin McCabe

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

+1 (binding) Thanks for the KIP. On Tue, May 19, 2020 at 2:57 PM Mickael Maison wrote: > Thanks Konstantine for the feedback (and vote)! > > 1) I've added example commands using the new formatters > > 2) I updated the Compatiblity section to be more explicit about the > need for recompilation

Re: [VOTE] KIP-612: Ability to Limit Connection Creation Rate on Brokers

+1 (binding) Thanks for the KIP, Anna! Regards, Rajini On Tue, May 19, 2020 at 9:32 AM Alexandre Dupriez < alexandre.dupr...@gmail.com> wrote: > +1 (non-binding) > > Thank you for the KIP! > > > Le mar. 19 mai 2020 à 07:57, David Jacot a écrit : > > > > +1 (non-binding) > > > > Thanks for

Re: [VOTE] KIP 585: Filter and conditional SMTs

+1 (non-binding) Thanks for working on this, Tom! This KIP will be very useful for connectors like Debezium. --Gunnar Am Fr., 15. Mai 2020 um 20:02 Uhr schrieb Konstantine Karantasis : > > +1 (binding) > > Thanks Tom. > > Konstantine > > On Fri, May 15, 2020 at 5:03 AM Andrew Schofield >

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

Thanks Konstantine for the feedback (and vote)! 1) I've added example commands using the new formatters 2) I updated the Compatiblity section to be more explicit about the need for recompilation 3) Good point, updated On Tue, May 19, 2020 at 3:18 AM Konstantine Karantasis wrote: > > Thanks

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi, Please, tell me how to unsubscribe. Thanks, Serhii On Mon, 18 May 2020, 23:44 Aakash Shah, wrote: > Hi Chris, > > I agree with your point. > > Randall, Konstantine, do you guys mind weighing in on any benefit of adding > asynchronous functionality using a Future in the KIP right now? It

Re: [VOTE] KIP-612: Ability to Limit Connection Creation Rate on Brokers

+1 (non-binding) Thank you for the KIP! Le mar. 19 mai 2020 à 07:57, David Jacot a écrit : > > +1 (non-binding) > > Thanks for the KIP, Anna! > > On Tue, May 19, 2020 at 7:12 AM Satish Duggana > wrote: > > > +1 (non-binding) > > Thanks Anna for the nice feature to control the connection

Re: [DISCUSS] KIP-612: Ability to Limit Connection Creation Rate on Brokers

Hi Anna, Thank you for your answers. 900. Sorry, I forgot the connection creation rate metric already allows users to detect excessive rates. I agree per-IP metrics would expose to a high-cardinality risk. 902. Thank you for the pointers. I will explore the existing stress test in Trogdor.

[jira] [Created] (KAFKA-10021) When reading to the end of the config log, check if fetch.max.wait.ms is greater than worker.sync.timeout.ms

Sanjana Kaundinya created KAFKA-10021: - Summary: When reading to the end of the config log, check if fetch.max.wait.ms is greater than worker.sync.timeout.ms Key: KAFKA-10021 URL:

Re: [VOTE] KIP-607: Add Metrics to Record the Memory Used by RocksDB to Kafka Streams

Thank you for voting! This KIP passes with: 4 binding +1 1 non-binding +1 0 -1 Best, Bruno On Fri, May 15, 2020 at 11:34 PM Matthias J. Sax wrote: > > +1 (binding) > > -Matthias > > On 5/15/20 11:48 AM, John Roesler wrote: > > Thanks, Bruno! > > > > I’m +1 (binding) > > > > -John > > > > On

Re: [DISCUSS] KIP-610: Error Reporting in Sink Connectors

Hi Randall, Thanks for the explanation! Excellent point about guaranteeing offsets in the async case. If we can guarantee that the offsets will be advanced only after the bad records are reported, then is there any value is the Future<> return type? I feel we can declare the function with a void

Re: [DISCUSS] KIP-590: Redirect Zookeeper Mutation Protocols to The Controller

Hi Boyang, I've got another question regarding the auto topic creation case. The KIP says: "Currently the target broker shall just utilize its own ZK client to create internal topics, which is disallowed in the bridge release. For above scenarios, non-controller broker shall just forward a

Re: [VOTE]: KIP-604: Remove ZooKeeper Flags from the Administrative Tools

+1 (non-binding). Thanks for the KIP. On Fri, May 15, 2020 at 12:41 AM Guozhang Wang wrote: > +1. > > Thanks Colin! > > Guozhang > > On Tue, May 12, 2020 at 3:45 PM Colin McCabe wrote: > > > Hi all, > > > > I'd like to start a vote on KIP-604: Remove ZooKeeper Flags from the > >

Re: [VOTE] KIP-612: Ability to Limit Connection Creation Rate on Brokers

+1 (non-binding) Thanks for the KIP, Anna! On Tue, May 19, 2020 at 7:12 AM Satish Duggana wrote: > +1 (non-binding) > Thanks Anna for the nice feature to control the connection creation rate > from the clients. > > On Tue, May 19, 2020 at 8:16 AM Gwen Shapira wrote: > > > +1 (binding) > > > >

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

See Changes: [github] KAFKA-10004: ConfigCommand fails to find default broker configs without -- [...truncated 3.09 MB...]

Re: [DISCUSS] KIP-616: Rename implicit Serdes instances in kafka-streams-scala

Hi John, Your suggestion looks interesting. I think it's technically doable. But I'm not sure that this is the better solution. I will try to explain. From the scala developers' perspective, `Serde` looks really like a typeclass. Typical typeclass in pure scala will look like this: ``` trait