Re: Converting a Stream to a Table - groupBy/reduce vs. stream.to/builder.table

Hi John and Guozhang Thanks to both of you. I will check with our developers if they want to adopt your suggestions. Using the same ValueTransformer for deduplication on both streams and tables might simplify things. We have eased the operational burden a bit by improving our topic provisioning s

[RESULTS] [VOTE] Release Kafka version 2.1.0

This vote passes with 10 +1 votes (3 bindings) and no 0 or -1 votes. +1 votes PMC Members: * Guozhang Wang * Jason Gustafson * Dong Lin Committers: * Vahid Hashemian * ManiKumar Reddy Community: * Jonathan Santilli * Eno Thereska * Andras Beni * Jakub Scholz * Satish Duggana 0 votes * No

Re: Converting a Stream to a Table - groupBy/reduce vs. stream.to/builder.table

Hi again, Patrik, You'll probably be interested in this recent Jira: https://issues.apache.org/jira/browse/KAFKA-7658 You have a good point about the overhead of going through an intermediate topic... I can see how explicit topic management is an operational burden, and you're also right that the

Re: Stream Metrics - Memory Analysis

Done. https://issues.apache.org/jira/browse/KAFKA-7660 br, Patrik On Mon, 19 Nov 2018 at 02:03, Guozhang Wang wrote: > Hello Patrik, > > Could you file a JIRA for your findings? Also what Kafka versions are you > using (could you add that to the ticket as well)? > > Could you provide some more e

Re: Kafka streams consumer/producer throttling

Hi Guozhang, I set client id like that: propsWithAppId.put(StreamsConfig.APPLICATION_ID_CONFIG, appId); propsWithAppId.put(StreamsConfig.CLIENT_ID_CONFIG, appId); propsWithAppId.put(ProducerConfig.CLIENT_ID_CONFIG, appId); propsWithAppId.put(ConsumerConfig.CLIENT_ID_CONFIG, appId); propsWithAppId.