Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

Good point, Gwen. We always set a non empty value for client id: https://github.com/apache/kafka/blob/2.2.0/clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java#L668 . But more importantly, connect client ids (for consumers, for example) were already of the form

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

I'm confused. Surely the default quota applies on empty client IDs too? otherwise it will be very difficult to enforce? So setting the client name will only change something if there's already a quota for that client? On the other hand, I fully support switching to "easy-to-wildcard" template for

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

I just realized that setting the client.id on the will now trigger any quota restrictions ( https://kafka.apache.org/documentation/#design_quotasconfig) on the broker. It seems like this PR will enforce quota policies that will either require admins to set limits for each task (since the chosen

Re: [DISCUSS] KIP-465: Add Consolidated Connector Endpoint to Connect REST API

Thanks for the KIP, Dan! This is a simple change that will make it easier to get the status of all of the connectors running in a Connect cluster, and I like the approach of adding a query parameter to the existing `connectors/` resource to be backward compatible and to avoid introducing another

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

See Changes: [ismael] MINOR: Extract Gradle and its plugins versions into dependencies.gradle -- Started by an SCM change [EnvInject] - Loading node environment

Build failed in Jenkins: kafka-2.2-jdk8 #98

See Changes: [jason] KAFKA-8066; Always close the sensors in Selector.close() (#6402) -- [...truncated 2.74 MB...] kafka.controller.PartitionLeaderElectionAlgorithmsTest >

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

hell yeah! +1 On Fri, Apr 5, 2019 at 9:08 AM Paul Davidson wrote: > Hi all, > > Since we seem to have agreement in the discussion I would like to start the > vote on KIP-411. > > See: > >

[jira] [Created] (KAFKA-8313) KafkaStreams state not being updated properly after shutdown

Eric created KAFKA-8313: --- Summary: KafkaStreams state not being updated properly after shutdown Key: KAFKA-8313 URL: https://issues.apache.org/jira/browse/KAFKA-8313 Project: Kafka Issue Type: Bug

Re: [VOTE] KIP-460: Admin Leader Election RPC

+1 On Wed, May 1, 2019 at 2:44 PM Jose Armando Garcia Sancio < jsan...@confluent.io> wrote: > Hi all, > > I would like to start the voting for KIP-460: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-460%3A+Admin+Leader+Election+RPC > > The thread discussion is here: >

Re: [DISCUSS] KIP-429 : Smooth Auto-Scaling for Kafka Streams

Hey Guozhang, thank you for the great write up. Overall the motivation and changes LGTM, just some minor comments: 1. In "Consumer Coordinator Algorithm", we could reorder alphabet points for 3d~3f from ["ready-to-migrate-partitions", "unknown-but-owned-partitions",

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

See Changes: [jason] KAFKA-8066; Always close the sensors in Selector.close() (#6402) -- [...truncated 2.41 MB...] org.apache.kafka.streams.test.OutputVerifierTest >

[jira] [Created] (KAFKA-8312) Rest advertised name is required while setting the listener to 0.0.0.0

Magesh kumar Nandakumar created KAFKA-8312: -- Summary: Rest advertised name is required while setting the listener to 0.0.0.0 Key: KAFKA-8312 URL: https://issues.apache.org/jira/browse/KAFKA-8312

[jira] [Created] (KAFKA-8311) Better consumer timeout exception handling

Boyang Chen created KAFKA-8311: -- Summary: Better consumer timeout exception handling Key: KAFKA-8311 URL: https://issues.apache.org/jira/browse/KAFKA-8311 Project: Kafka Issue Type:

Re: [VOTE] KIP-460: Admin Leader Election RPC

+1 Thanks for the KIP. -Jason On Wed, May 1, 2019 at 2:44 PM Jose Armando Garcia Sancio < jsan...@confluent.io> wrote: > Hi all, > > I would like to start the voting for KIP-460: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-460%3A+Admin+Leader+Election+RPC > > The thread discussion

Build failed in Jenkins: kafka-2.1-jdk8 #178

See Changes: [jason] KAFKA-8066; Always close the sensors in Selector.close() (#6402) -- [...truncated 1.92 MB...] org.apache.kafka.common.requests.DeleteAclsRequestTest >

Re: [VOTE] KIP-411: Make default Kafka Connect worker task client IDs distinct

Looks helpful. +1 -Jason On Tue, Apr 30, 2019 at 5:54 PM Randall Hauch wrote: > Nice simple improvement. Thanks, Paul! > > +1 (binding) > > Randall > > On Mon, Apr 29, 2019 at 5:06 PM Magesh Nandakumar > wrote: > > > Looks good to me and a very useful feature. > > > > +1 ( non-binding) > > >

[jira] [Resolved] (KAFKA-8310) CommandLineUtils.parseKeyValueArgs --property flag too greedy when splitting key=value pairs

[ https://issues.apache.org/jira/browse/KAFKA-8310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jordan Moore resolved KAFKA-8310. - Resolution: Duplicate Fix Version/s: 2.1.0 Whoops. Need to upgrade my CLI clients.

[jira] [Created] (KAFKA-8310) CommandLineUtils.parseKeyValueArgs --property flag too greedy when splitting key=value pairs

Jordan Moore created KAFKA-8310: --- Summary: CommandLineUtils.parseKeyValueArgs --property flag too greedy when splitting key=value pairs Key: KAFKA-8310 URL: https://issues.apache.org/jira/browse/KAFKA-8310

[VOTE] KIP-460: Admin Leader Election RPC

Hi all, I would like to start the voting for KIP-460: https://cwiki.apache.org/confluence/display/KAFKA/KIP-460%3A+Admin+Leader+Election+RPC The thread discussion is here: https://www.mail-archive.com/dev@kafka.apache.org/msg97226.html Thanks! -Jose

Build failed in Jenkins: kafka-2.0-jdk8 #257

See Changes: [jason] KAFKA-8066; Always close the sensors in Selector.close() (#6402) -- [...truncated 425.91 KB...] kafka.controller.PartitionStateMachineTest >

Jenkins build is back to normal : kafka-2.2-jdk8 #97

See

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

See

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

See Changes: [jason] KAFKA-8066; Always close the sensors in Selector.close() (#6402) -- Started by an SCM change [EnvInject] - Loading node environment variables.

[jira] [Resolved] (KAFKA-8066) ReplicaFetcherThread fails to startup because of failing to register the metric.

[ https://issues.apache.org/jira/browse/KAFKA-8066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Gustafson resolved KAFKA-8066. Resolution: Fixed Fix Version/s: 2.2.1 2.1.2

Build failed in Jenkins: kafka-2.1-jdk8 #177

See Changes: [bill] KAFKA-8298: Fix possible concurrent modification exception (#6643) -- [...truncated 464.80 KB...] kafka.server.KafkaConfigTest >

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

Perhaps inlining is the wrong terminology. It doesn’t require that a lambda with the full downstream topology be defined inline - it can be a method reference as with Ivan’s original suggestion. The advantage of putting the predicate and its downstream logic (Consumer) together in branch() is

[VOTE] KIP-464: Defaults for AdminClient#createTopic

Hello Everyone! Kicking off the voting for https://cwiki.apache.org/confluence/display/KAFKA/KIP-464%3A+Defaults+for+AdminClient%23createTopic You can see discussion thread here (please respond with suggestions on that thread):

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

I'm less enthusiastic about inlining the branch logic with its downstream functionality. Programs that have deep branch trees will quickly become harder to read as a single unit. On Tue, Apr 30, 2019 at 8:34 PM Paul Whalen wrote: > Also +1 on the issues/goals as Michael outlined them, I think

[DISCUSS] KIP-465: Add Consolidated Connector Endpoint to Connect REST API

The intent of this KIP is to add a consolidate endpoint to connect that gives consumers of the api a one stop shop for all their connector info needs. https://cwiki.apache.org/confluence/display/KAFKA/KIP-465%3A+Add+Consolidated+Connector+Endpoint+to+Connect+REST+API thanks, dan

[jira] [Created] (KAFKA-8309) KIP-465: Add Consolidated Connector Endpoint to Connect REST API

dan norwood created KAFKA-8309: -- Summary: KIP-465: Add Consolidated Connector Endpoint to Connect REST API Key: KAFKA-8309 URL: https://issues.apache.org/jira/browse/KAFKA-8309 Project: Kafka

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

See Changes: [cmccabe] KAFKA-7992: Introduce start-time-ms metric (#6318) [github] KAFKA-8298: Fix possible concurrent modification exception (#6643) -- Started by an

Re: [VOTE] KIP-462 : Use local thread id for KStreams

Thank you all for the vote! Now we have 3 binding votes from Guozhang, Bill and Matthias. Will close this KIP and put it in 2.3 release. Boyang Get Outlook for iOS From: Bill Bejeck Sent: Wednesday, May 1, 2019 8:39:19 AM To:

Re: [VOTE] KIP-462 : Use local thread id for KStreams

+1(binding) On Wed, May 1, 2019 at 3:07 AM Matthias J. Sax wrote: > +1 (binding) > > > -Matthias > > On 4/26/19 6:16 AM, Boyang Chen wrote: > > Hey friends, > > > > I would like to start the vote for KIP-462: > > >

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

See Changes: [github] KAFAK-3522: add API to create timestamped stores (#6601) [github] KAFKA-3729: Revert adding Serde auto-config (#6630) -- [...truncated 2.40 MB...]

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

See Changes: [github] KAFAK-3522: add API to create timestamped stores (#6601) [github] KAFKA-3729: Revert adding Serde auto-config (#6630) -- Started by an SCM change

Re: [VOTE] KIP-462 : Use local thread id for KStreams

+1 (binding) -Matthias On 4/26/19 6:16 AM, Boyang Chen wrote: > Hey friends, > > I would like to start the vote for KIP-462: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-462%3A+Use+local+thread+id+for+KStreams > > if you have questions, feel free to raise in the discussion thread,

Re: [DISCUSS] KIP-455: Create an Administrative API for Replica Reassignment

Hi Colin, Thanks for KIP-455!  yes. KIP-236, etc. will depend on it.  It is the good direction to go for the RPC.  Regarding storing the new reassignments & original replicas at the topic/partition level.  I have some concerns when controller is failing over, and the scalability of scanning

Re: [DISCUSS] KIP-236 Interruptible Partition Reassignment

Hi Jason, Sorry for the late response.  been busy.  I have taken a brief look at Colin's KIP-455. It's a good direction for Reassignments. I think KIP-236, KIP-435,  KIP-455 need some consensus / coordination for where the new reassignment data AND the original replicas is stored.   The