Re: [VOTE] 2.6.2 RC1

I verified the signatures and checksums, ran the tests, and spot-checked the license. I'm +1 (binding). Thanks for driving this, Sophie! -John On Thu, 2021-04-08 at 16:19 -0700, Guozhang Wang wrote: > Looked over the javadocs and web docs again. Download the jars and check > the license files ar

Re: [VOTE] 2.7.1 RC2

Hi Mickael, I verified the signatures and checksums, ran the tests, and spot-checked the license. I'm +1 (binding). Thanks for driving this release! -John On Fri, 2021-04-09 at 11:07 +0100, Mickael Maison wrote: > Hi, > > Here is a successful build of 2.7.1 RC2: > https://ci-builds.apache.org/

Re: [VOTE] KIP-732: Deprecate eos-alpha and replace eos-beta with eos-v2

Thanks, Sophie, I'm +1 (binding) -John On Wed, 2021-04-14 at 16:59 -0700, Sophie Blee-Goldman wrote: > Hey all, > > I'd like to kick off the vote on KIP-732, to deprecate eos-alpha in Kafka > Streams and migrate away from the "eos-beta" terminology by replacing it > with "eos-v2" to shore up us

[RESULTS] [VOTE] Release Kafka version 2.8.0

This vote passes with 6 +1 votes (4 binding) and no 0 or -1 votes. +1 votes PMC Members: * Bill Bejeck * Randall Hauch * Colin McCabe * John Roesler Community: * Israel Ekpo * Satish Duggana 0 votes * No votes -1 votes * No votes Vote thread: https://lists.apache.org/thread.html

[ANNOUNCE] Apache Kafka 2.8.0

, Ismael Juma, Ivan Ponomarev, Ivan Yurchenko, jackyoh, James Cheng, James Yuzawa, Jason Gustafson, Jesse Gorzinski, Jim Galasyn, John Roesler, Jorge Esteban Quilcate Otoya, José Armando García Sancio, Julien Chanaud, Julien Jean Paul Sirocchi, Justine Olshan, Kengo Seki, Kowshik Prakasam, leah, Lee

Re: KafkaStreams Scala: Replace FunctionsCompatConversions

Hi Rama, There has been discussion on and off for building something like this into the library, and I think it’s a good idea, but we haven’t had anyone draft a proposal. My bias with Scala is actually to avoid using implicits for nontrivial logic like this. It’s convenient, but it also makes

Re: Issue accessing apache.org

Hello Laxmikant, The folks on these mailing lists are just developers for each individual project. We don’t have any visibility into the Apache infrastructure. My best suggestion is to file a ticket in the INFRA project here: https://issues.apache.org/jira Those are the folks who run the infr

Re: Backport of KAFKA-8562?

Hi Josep, It doesn't look to me like anyone was planning to do the backport, so if you're volunteering to do it, I think it would be appreciated. Thanks, -John On Mon, May 10, 2021, at 03:36, Josep Prat wrote: > Hi all, > > We are facing the problem described in > https://issues.apache.org/jira

Re: KafkaStreams Scala: Replace FunctionsCompatConversions

SupplierAsJava, > ValueMapperFromFunction, > ValueMapperWithKeyFromFunction, > ValueTransformerSupplierAsJava, > ValueTransformerSupplierWithKeyAsJava > } > > > On Sun, May 9, 2021 at 5:30 PM John Roesler wrote: > > > Hi Rama, > > > > Th

Re: KafkaStreams Scala: Replace FunctionsCompatConversions

roducer/serdes exception handler, serdes, and any other > class_config. > > Again - thank you very much. > I mostly agree with the strong advice against implicits - but I kind of > need to understand why my logic is so wrong. > > rama > > On Mon, May 10, 2021 at 11:

Re: [VOTE] KIP-740: Use TaskId instead of String for the taskId field in TaskMetadata

Thanks for these updates, Sophie, Unfortunately, I have some minor suggestions: 1. "Topic Group" is a vestigial term from the early days of the codebase. We call a "topic group" a "subtopology" in the public interface now (although "topic group" is still used internally some places). For user-fac

Re: KafkaStreams Scala: Replace FunctionsCompatConversions

natives, I came across this library -- > > https://github.com/bakdata/kafka-error-handling > > It might be what we need, and also may be good to integrate into > > kafka-streams eventually. > > > > Thanks again :) > > rama > > > > > > On Tue

Re: [VOTE] KIP-740: Use TaskId instead of String for the taskId field in TaskMetadata

e moved the discussion over to a [DISCUSS] thread, > > > > where > > > > > it should have been taking place all > > > > > along. I'll officially kick off the vote again, but since this KIP has > > > > > been through a signific

Re: [DISCUSS] KIP-743: Deprecate config value 0.10.0-2.4 of Streams built-in metrics version config

Thanks for opening this discussion, Bruno! I wonder if it would be ok to simply drop that config value in 3.0 instead of 4.0. Config values are a bit different than Java APIs, since many users would be using property files or string constants instead of referencing the "official" constants define

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

Hey there, Ivan! In typical fashion, I'm going to make a somewhat outlandish proposal. I'm hoping that we can side-step some of the complications that have arisen. Please bear with me. It seems like `distinct()` is not fundamentally unlike other windowed "aggregation" operations. Your concern abo

Re: [VOTE] KIP-741: Change default serde to be null

+1 (binding) from me. Thanks for the KIP! -John On Mon, May 24, 2021, at 18:10, Sophie Blee-Goldman wrote: > +1 binding > > thanks for the KIP > -Sophie > > On Mon, May 24, 2021 at 2:02 PM Walker Carlson > wrote: > > > +1 (non-binding) from me, Leah > > > > Walker > > > > On Mon, May 24, 2021

Re: [VOTE] KIP-743: Remove config value 0.10.0-2.4 of Streams built-in metrics version config

+1 (binding) Thanks, Bruno! -John On Fri, May 21, 2021, at 10:58, Sophie Blee-Goldman wrote: > +1 (binding) > > Thanks Bruno! > > On Fri, May 21, 2021 at 8:06 AM Guozhang Wang wrote: > > > +1, thanks! > > > > On Fri, May 21, 2021 at 12:45 AM Bruno Cadonna wrote: > > > > > Hi, > > > > > > I'd

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

ows.with(Duration.ofSeconds(10))).distinct() > > > > produces only > > ([key@4000/4000], 4) > ([key@23000/23000], 23) > > because all the records bigger than 7 are stuck together in one session. > Setting inactivity gap to 9 seconds will return three records: &g

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

thub.com/apache/kafka/pull/10869 Please let me know if you have any concerns! Thank you, -John On Mon, Oct 12, 2020, at 22:18, John Roesler wrote: > Hello all, > > While reviewing the KIP document, I realized that I hadn't > submitted a PR to migrate the KStream.process() meth

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

s://issues.apache.org/jira/browse/KAFKA-10844 > >> > >> Thus, it seems best to exclude this topic from this KIP, and do a > >> separate KIP for it (if necessary, we can "pause" this KIP until the > >> repartition KIP is done). It's a long standing "

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

erations are > also verbs. I do not think that SQL and the Java Stream API are good > arguments to not use a verb. > > Best, > Bruno > > > On 10.07.21 19:11, John Roesler wrote: > > Hi Ivan, > > > > Sorry for the silence! > > > > I have j

Re: [DISCUSS] KIP-763: Range queries with open endpoints

Thanks for the KIP, Patrick! I think your KIP is well motivated. It's definitely a bummer to have to iterate over the full store as a workaround for open-ended ranges. I agree with your pragmatic approach here. We have recently had a couple of other contributions to the store APIs (prefix and rev

Re: [VOTE] KIP-763: Range queries with open endpoints

Thank you, Patrick, +1 (binding) from me as well! Thanks, -John On Thu, 2021-07-22 at 10:40 +0200, Bruno Cadonna wrote: > Hi Patrick, > > Thank you for the KIP! > > +1 (binding) > > Best, > Bruno > > On 22.07.21 03:47, Luke Chen wrote: > > Hi Patrick, > > I like this KIP! > > > > +1 (non-bi

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

earch. When we teach KStreams, we always say that > KStreams are just like other streaming APIs, and they have roots in SQL > queries. Users know what `distinct` is and they expect it to be in the API. > > > Regards, > > Ivan > > > 13.07.2021 0:10, John Roesler пи

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

) distinct(Materialized) It's a small update, but an important one, since people will inevitably need to customize the state store for the operation. Thanks, John On Thu, 2021-07-22 at 13:58 -0500, John Roesler wrote: > Hi Ivan, > > Thanks for the reply. > > 1. I think I migh

Re: [DISCUSS] Apache Kafka 3.0.0 release plan with new updated dates

Hello Konstantine, Someone just called to my attention that KAFKA-12724 had not been marked as a 3.0 blocker. We never added 2.8 to the Streams upgrade system test suite. This isn't a blocker in that it is a problem, but we should make sure that Streams is actually upgradable before releasing 3.0.

Re: [DISCUSS] KIP-655: Windowed "Distinct" Operation for KStream

an get behind it. > > John, good catch about the missing overloads! > BTW, the overload with Named should be there regardless of stateful or > stateless. > > Best, > Bruno > > On 22.07.21 20:58, John Roesler wrote: > > Hi Ivan, > > > > Thanks for t

Re: [DISCUSS] Apache Kafka 2.8.1 release

Thanks, David! +1 from me as well. -John On Mon, 2021-08-16 at 12:00 -0400, Bill Bejeck wrote: > Thanks for volunteering to run the release David. > > It's a +1 for me. > > Bill > > On Mon, Aug 16, 2021 at 1:14 AM Konstantine Karantasis < > kkaranta...@apache.org> wrote: > > > Thanks for vol

Re: [VOTE] KIP-766: fetch/findSessions queries with open endpoints for SessionStore/WindowStore

Thanks, Luke! I'm sorry I missed your discussion thread. The KIP looks good to me! I'm +1 (binding) Thanks, -John On Tue, 2021-08-17 at 16:40 +0800, Luke Chen wrote: > Hi all, > I'd like to start to vote for > *KIP-766: fetch/findSessions queries with open endpoints for > WindowStore/SessionSto

Re: [DISCUSS] KIP-775: Custom partitioners in foreign key joins

Thanks for the KIP, Victoria! This is a great catch. As fas as my memory serves, we totally missed this case in the design of FK joins. tl;dr: I'm wondering if it might be better to instead introduce a way to specify the partitioning scheme when we create a KTable and then just use it when we joi

Re: [DISCUSS] KIP-775: Custom partitioners in foreign key joins

specify the same for #repartition > etc as well?). Given that rationale, I'm slightly leaning towards the > current proposal in the KIP doc, i.e. just fixing for this FK operator > only, with the easy approach that requires users themselves to set > partitioners accordingly. > > &g

Re: [DISCUSS] KIP-775: Custom partitioners in foreign key joins

e settable using `withXYZ` builder methods. If that proposal isn't clear, I'd be happy to provide a code sketch. Thanks in advance for your consideration, and thanks again for driving this, -John On Wed, 2021-09-22 at 17:34 -0500, John Roesler wrote: > Thanks, Guozhang! > > I a

Re: [VOTE] KIP-775: Custom partitioners in foreign key joins

+1 (binding) Thanks, Victoria! -John On Tue, Sep 28, 2021, at 16:29, Adam Bellemare wrote: > +1 (non-binding) > > Glad to see this in here :) > > On Tue, Sep 28, 2021 at 5:11 PM Bill Bejeck wrote: > >> +1 (binding) >> >> On Tue, Sep 28, 2021 at 12:59 PM Matthias J. Sax wrote: >> >> > +1 (bindi

Re: [VOTE] Add TaskId field to StreamsException

Thanks, Sophie, +1 from me. I was a little apprehensive about the potential to break exception handler logic, but I agree with your comment in the "compatibility" section: Identifying the causes of exceptions is always kind of chaotic and this seems like more of an improvement than anything. Reg

Re: KIP Process Needs Improvement

Good morning Knowles, Thank you for sharing this feedback. I think your frustration is well founded. I think most/all of the active committers carry around a sense of guilt about KIPs that we haven’t been able to review. We do have a responsibility to hold auditable, public design discussions b

Re: [DISCUSS] KIP-779: Allow Source Tasks to Handle Producer Exceptions

Good morning, Knowles, Thanks for the KIP! To address your latest questions, it is fine to call for a vote if a KIP doesn't generate much discussion. Either the KIP was just not controversial enough for anyone to comment, in which case a vote is appropriate; or no one had time to review it, in wh

Re: [DISCUSS] KIP-779: Allow Source Tasks to Handle Producer Exceptions

y have at the time to inform decisions on > what to do with these producer exceptions. > > I have updated the KIP and PR. > > Knowles > > On Wed, Oct 27, 2021 at 1:03 PM John Roesler wrote: > > > Good morning, Knowles, > > > > Thanks for the KIP! > &

Re: [DISCUSS] KIP-791: Add Record Metadata to State Store Context

Thanks for the KIP, Patrick! It looks like you addressed Guozhang's and Bruno's very good feeback, and I like the result. The example especially helps clarify how this property might be useful. I'm in favor of this proposal. Thanks, -John On Fri, 2021-11-05 at 12:03 +0100, Bruno Cadonna wrote:

Re: [VOTE] KIP-791: Add Record Metadata to State Store Context

+1 (binding) from me. Thanks, Patrick! On Mon, 2021-11-08 at 14:08 -0800, Guozhang Wang wrote: > +1, thanks Patrick! > > > Guozhang > > On Mon, Nov 8, 2021 at 5:44 AM Vasiliki Papavasileiou > wrote: > > > Hi Patrick, > > > > Having the recordMetadata available in the state stores is fundame

[DISCUSS] KIP-796: Interactive Query v2

Hello all, I'd like to start the discussion for KIP-796, which proposes a revamp of the Interactive Query APIs in Kafka Streams. The proposal is here: https://cwiki.apache.org/confluence/x/34xnCw I look forward to your feedback! Thank you, -John

Re: [DISCUSS] KIP-799 Align behaviour for producer callbacks with documented behaviour

Thanks for the KIP, Séamus! I agree that the current situation you’re describing doesn’t seem ideal, and it’s probably worth a slight behavior change to fix it. It’s too bad that we introduced that placeholder record, since it seems less error prone for users if we have the invariant that exact

Re: [DISCUSS] KIP-799 Align behaviour for producer callbacks with documented behaviour

ested > in implementation details there is a draft PR linked in the KIP with that > refactoring done, so any discussion on that topic can take place in Github > / JIRA. > > Regards, > Séamus. > > On Thu, 11 Nov 2021 at 14:33, John Roesler wrote: > > > Thanks for the

Re: [VOTE] KIP-779: Allow Source Tasks to Handle Producer Exceptions

Thanks, Knowles! I'm +1 (binding) -John On Wed, 2021-11-10 at 12:42 -0500, Christopher Shannon wrote: > +1 (non-binding). This looks good to me and will be useful as a way to > handle producer errors. > > On Mon, Nov 8, 2021 at 8:55 AM Knowles Atchison Jr > wrote: > > > Good morning, > > > >

Re: [DISCUSS] KIP-796: Interactive Query v2

Hello again, all, Just bumping this discussion on a new, more flexible Interactive Query API in Kafka Streams. If there are no concerns, I'll go ahead and call a vote on Monday. Thanks! -John On Tue, 2021-11-09 at 17:37 -0600, John Roesler wrote: > Hello all, > > I'

Re: [DISCUSS] KIP-796: Interactive Query v2

but the javadocs refer to Optional. > Not > sure which is intended for this API, but if is supposed to be the return > type, do you perhaps > mean for it to be Optional.ofEmpty() and Optional.of(non-empty set) > rather than Optional.of(empty set) and Optional.of(non-empty set) ? >

Re: [DISCUSS] KIP-796: Interactive Query v2

will the result be? Also I noticed the Position > > returning method is in InteractiveQueryRequest and InteractiveQueryResult > > is named differently, any particular reason? > > > > Best, > > Patrick > > > > > > On Fri, Nov 12, 2021 at 12:29 AM

Re: [DISCUSS] KIP-796: Interactive Query v2

rdes(); > } > > And then the result itself can also provide some built-in functions to do > the deser upon returning results, so that user's code would not get more > complicated. The benefit is that we end up with a single function in > `KafkaStreams`, and the inner store

Re: [DISCUSS] KIP-796: Interactive Query v2

t; metered stores, would it make sense to add them explicitly to the KIP and > also to Javadocs if possible? That would guide the future contributors. > WDYT? > > The other question I have is (may be irrelevant) but with these changes, is > there going to be any impact on remote state

Re: [DISCUSS] KIP-796: Interactive Query v2

On Tue, 2021-11-16 at 15:59 -0800, Guozhang Wang wrote: > Thanks John! Some more thoughts inlined below. > > On Mon, Nov 15, 2021 at 10:07 PM John Roesler wrote: > > > Thanks for the review, Guozhang! > > > > 1. This is a great point. I fell into the age-old trap

[VOTE} KIP-796: Interactive Query v2

Hello all, I'd like to open the vote for KIP-796, which proposes a revamp of the Interactive Query APIs in Kafka Streams. The proposal is here: https://cwiki.apache.org/confluence/x/34xnCw Thanks to all who reviewed the proposal, and thanks in advance for taking the time to vote! Thank you, -Jo

Re: [VOTE] KIP-796: Interactive Query v2

Obviously, I will be voting +1 (binding) Thanks, -John On Wed, 2021-11-17 at 17:27 -0600, John Roesler wrote: > Hello all, > > I'd like to open the vote for KIP-796, which proposes > a revamp of the Interactive Query APIs in Kafka Streams. > > The proposal is here: >

Re: [DISCUSS] KIP-796: Interactive Query v2

rom `query`, it seems > more exception types are possible from KIP-216: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-216%3A+IQ+should+throw+different+exceptions+for+different+errors, > should we include all in the javadocs? > > > Guozhang > > > > On Wed, N

Re: Errors thrown from a KStream transformer are swallowed, eg. StackOverflowError

Thanks for pointing that out, Scott! You’re totally right; that should be a Throwable. Just to put it out there, do you want to just send a quick PR? If not, no worries. I’m just asking because it seems like you’ve already done the hard part and it might be nice to get the contribution credit.

Re: [ANNOUNCE] New Kafka PMC Member: Tom Bentley

Congratulations, Tom! On Thu, Nov 18, 2021, at 17:53, Konstantine Karantasis wrote: > Congratulations Tom! > > Konstantine > > > On Thu, Nov 18, 2021 at 2:44 PM Luke Chen wrote: > >> Congrats, Tom! >> >> Guozhang Wang 於 2021年11月19日 週五 上午1:13 寫道： >> >> > Congrats Tom! >> > >> > Guozhang >> > >> >

Re: [VOTE] KIP-798 Add possibility to write kafka headers in Kafka Console Producer

Hi Florin, Thanks for the KIP! I think the assumption that header values are UTF-8 strings might not hold up in the long run, but it seems like we can easily add a property later to specify the format. It seems like this scope is probably a handy addition on its own. I’m +1 (binding) Thanks

Re: [VOTE} KIP-796: Interactive Query v2

ms so +1 > > > (non-binding) from me. > > > > > > Thank you John! > > > > > > On Thu, Nov 18, 2021 at 9:45 PM Patrick Stuedi > > > > > wrote: > > > > > > > +1 (non-binding), thanks John! > > > > -Patrick >

Re: [VOTE] KIP-799: Align behaviour for producer callbacks with documented behaviour

Thanks, Séamus! I'm +1 (binding). On Mon, 2021-11-29 at 16:14 +, Séamus Ó Ceanainn wrote: > Hi everyone, > > I'd like to start a vote for KIP-799: Align behaviour for producer > callbacks with documented behaviour >

Re: [DISCUSS] KIP-805: Add range and scan query support in IQ v2

Thanks for the KIP, Vicky! This KIP will help fill in the parity gap between IQ and IQv2. One thing I noticed, which looks like just a typo is that the value type of the proposed RangeQuery should probably be KeyValueIterator, right? Otherwise, it looks good to me! Thanks, -John On Mon, 2021-1

Re: [VOTE] KIP-805: Add range and scan query support in IQ v2

Thanks for the KIP, Vicky! I’m +1 (binding) -John On Tue, Nov 30, 2021, at 14:51, Vasiliki Papavasileiou wrote: > Hello everyone, > > I would like to start a vote for KIP-805 that adds range and scan KeyValue > queries in IQ2. > > The KIP can be found here: > https://cwiki.apache.org/confluence/

Re: [VOTE] KIP-806: Add session and window query over KV-store in IQv2

Hi Patrick, thanks for the KIP! I hope you, Guozhang, and Luke don't mind if I share some thoughts: 1. I think you just meant to remove that private constructor from the KIP, right? 2. I think WindowRangeQuery#withWindowRage(windowLower, windowUpper) is the version that yields an iterator over b

Re: [VOTE] KIP-806: Add session and window query over KV-store in IQv2

; optimizations to future KIPs. > > Best, > Patrick > > On Tue, Dec 14, 2021 at 1:02 AM Guozhang Wang wrote: > > > Hi John, > > > > Please see my follow-up comments inlined below. > > > > On Mon, Dec 13, 2021 at 2:26 PM John Roesler wrote: > &g

Re: [VOTE] KIP-806: Add session and window query over KV-store in IQv2

:34 -0600, John Roesler wrote: > Thanks for the update, Patrick! > > Tl;dr: I'm +1 (binding) > > I just reviewed the KIP again (I hope you don't mind, I > fixed a couple of missed renames in the text and examples). > > One of the design of IQv2 is to make proposing

Re: [VOTE] KIP-810: Allow producing records with null values in Kafka Console Producer

Thanks Mickael! I’m +1 (binding) Thanks, John On Tue, Jan 4, 2022, at 08:53, Israel Ekpo wrote: > Thanks for the KIP, Mickael > > Looks great! > > +1 (non-binding) > > > > On Tue, Jan 4, 2022 at 5:24 AM Mickael Maison > wrote: > >> Hi, >> >> I'd like to start a vote on KIP-810 that adds the opt

Re: [DISCUSS] KIP-508: Make Suppression State Queriable - rebooted.

t; > > I updated the PR applying the API changes we discussed above. I am now > > updating the KIP document. > > > > Thanks, > > Dongjin > > > > On Sat, Sep 19, 2020 at 10:42 AM John Roesler wrote: > > > >> Hi Dongjin, > >> > >

Re: [VOTE] KIP-663: API to Start and Shut Down Stream Threads and to Request Closing of Kafka Streams Clients

Streams client will > transit to ERROR if the last alive stream thread dies exceptionally. > This corresponds to the current behavior. > > I will not restart voting and keep the votes so far. > > Best, > Bruno > > On 22.09.20 01:19, John Roesler wrote: > >

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

d have something like > > `RecordFactory.withKeyValue(...).withTimestamp(...).withHeaders(...).build()`. > But it looks rather verbose? > > The other question is of course, to what extend to we want to keep the > distinction between "primary" and "secondary" data? To m

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

something, I took a look at the PR and I didn't > see any spots where I thought it would be empty. Perhaps an example of a > Punctuator using (and not using) the new API would clear things up. > > Best, > Paul > > On Tue, Sep 29, 2020 at 4:10 PM John Roesler wrote: >

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

realizing it. What I’m hoping to do is just make the situation explicit and get rid of the dummy values. Thanks, John On Tue, Sep 29, 2020, at 20:01, John Roesler wrote: > Thanks for the review, Paul! > > I had read some of that debate before. There seems to be some subtext > there,

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

ould be asking for trouble. > Imo, if you > want to forward from a Punctuator, you need to store the info you need in > order to > set the timestamp, or make one up yourself > > (the one alternative I can think of here is that maybe we could pass in the > current > partit

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

d put > > > the timestamp field in RecordMetadata. Sorry for not giving things a > > > closer look > > > before responding! I'm not sure my original message made much sense given > > > the misunderstanding, but thanks for responding anyway :P > > > >

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

plier` class -- should we also deprecate the corresponding > existing ones that take the old `ProcessorSupplier`? > > > -Matthias > > > On 9/30/20 7:46 AM, John Roesler wrote: > > Thanks Paul and Sophie, > > > > Your feedback certainly underscores t

Re: [DISCUSS] KIP-508: Make Suppression State Queriable - rebooted.

; It seems like it must be a ReadOnlyKeyValueStore. Does that sound right? > > Yes, it is. Would it be better to add a detailed description of how this > feature effects interactive query, with examples? > > Best, > Dongjin > > On Tue, Sep 29, 2020 at 10:31 AM John Roesle

Re: [DISCUSS] Release Deadlines

Thanks for this, Matthias! I’m in favor. I’m glad we have all been working hard to stabilize our releases and offer a high quality project, even if it means delays. However, the last several releases have demonstrated that we consistently need more time than we have allocated. Rather than risk

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

he/kafka/pull/9361 I know it's a bit on the heavy side; I've annotated the PR to try and ease the reviewer's job. I'd greatly appreciate it if anyone can take the time to review. Thanks, -John On Wed, 2020-09-30 at 10:16 -0500, John Roesler wrote: > Thanks, Matthias! >

Re: [VOTE] KIP-653: Upgrade log4j to log4j2

Thanks for the KIP, Dongjin! I’ve just reviewed the KIP document, and it looks good to me. I’m +1 (binding) Thanks, John On Fri, Oct 2, 2020, at 19:11, Gwen Shapira wrote: > +1 (binding) > > A very welcome update :) > > On Tue, Sep 22, 2020 at 9:09 AM Dongjin Lee wrote: > > > > Hi devs, > >

Re: [DISCUSS] Apache Kafka 2.7.0 release

hanks for letting me know, I've added KIP-662 to the release > > > > plan. > > > > > > > > > -Bill > > > > > > > > > > > > > > > > > > On Mon, Sep 7, 2020 at 11:33 AM Bruno Cadonna < > > &g

Re: [DISCUSS] KIP-508: Make Suppression State Queriable - rebooted.

rough one by this weekend. > > Regards, > Dongjin > > On Thu, Oct 1, 2020 at 4:52 AM John Roesler wrote: > > > Thanks Dongjin, > > > > It typically is nicer to be able to see usage examples, so > > I'd certainly be in favor if you're willing to add

Re: [DISCUSS] KIP-676: Respect the logging hierarchy

Thanks for this KIP Tom, Just to clarify the impact: In your KIP you described a situation in which the root logger is configured at INFO, an "kafka.foo" is configured at TRACE, and then "kafka.foo.bar" is resolved to INFO. Assuming this goes into 3.0, would it be the case that if I had the above

Re: [DISCUSS] KIP-676: Respect the logging hierarchy

which would be TRACE both before and after upgrading. > > I've added more of an explanation to the KIP, since it wasn't very clear. > > Thanks for taking a look. > > Tom > > On Wed, Oct 7, 2020 at 4:29 PM John Roesler wrote: > > > Thanks for this KIP T

Re: [DISCUSSION] python code style checks

Thanks Nikolay, Sounds good to me in principle. I think linters serve a useful purpose. When it comes to the specific configuration, maybe you can open a POC PR so we can see what the formatter will do. Thanks, John On Fri, Oct 9, 2020, at 05:25, Brandon Brown wrote: > I love that idea, black

Re: [VOTE] KIP-676: Respect the logging hierarchy

+1 (binding) Thanks for the KIP! -John On Fri, Oct 9, 2020, at 05:57, Dongjin Lee wrote: > +1. (Non-binding) > > Thanks, > Dongjin > > On Fri, Oct 9, 2020 at 6:50 PM Tom Bentley wrote: > > > Hi all, > > > > KIP-676 is pretty trivial and the comments on the discussion thread seem to > > be fav

Re: [VOTE] KIP-478 Strongly Typed Streams Processor API

gt; > SGTM. > > On 10/1/20 2:50 PM, John Roesler wrote: > > Hello again, all, > > > > I'm sorry to make another tweak to this KIP, but during the > > implementation of the design we've just agreed on, I > > realized that Processors would almost never

Re: [VOTE] KIP-671: Add method to Shutdown entire Streams Application

t;>>> > > > >>>> One minor nit: you should also mention the global-thread that also > > > needs > > > >>>> to be shutdown if requested by the user. > > > >>>> > > > >>>> Minor side question: sho

Re: [VOTE] KIP-671: Add method to Shutdown entire Streams Application

global thread on a specific type of exception > (OffsetOutOfRange). If we want to consider expanding that to allow users > to choose to restart the thread, then KIP-406 seems like the more > appropriate place to engage in that discussion. > > On Wed, Oct 14, 2020 at 7:13 AM John Roe

Re: [ANNOUNCE] New committer: David Jacot

Congratulations, David! -John On Fri, Oct 16, 2020, at 20:15, Konstantine Karantasis wrote: > Congrats, David! > > Konstantine > > > On Fri, Oct 16, 2020 at 3:36 PM Ismael Juma wrote: > > > Congratulations David! > > > > Ismael > > > > On Fri, Oct 16, 2020 at 9:01 AM Gwen Shapira wrote: > >

Re: [ANNOUNCE] New committer: A. Sophie Blee-Goldman

Congratulations, Sophie! -John On Mon, 2020-10-19 at 10:52 -0700, Kowshik Prakasam wrote: > Congrats Sophie! > > > Cheers, > Kowshik > > > On Mon, Oct 19, 2020 at 10:31 AM Bill Bejeck wrote: > > > Congratulations Sophie! > > > > -Bill > > > > On Mon, Oct 19, 2020 at 12:49 PM Leah Thomas w

Re: [ANNOUNCE] New committer: Chia-Ping Tsai

Congratulations, Chia-Ping! -John On Mon, 2020-10-19 at 10:51 -0700, Kowshik Prakasam wrote: > Congrats! > > > Cheers, > Kowshik > > > On Mon, Oct 19, 2020 at 10:40 AM Bruno Cadonna wrote: > > > Congrats! > > > > Best, > > Bruno > > > > On 19.10.20 19:39, Sophie Blee-Goldman wrote: > > > C

Re: [VOTE] KIP-671: Add method to Shutdown entire Streams Application

now, > Walker > > On Wed, Oct 14, 2020 at 12:51 PM John Roesler wrote: > > > Thanks, Sophie, > > > > That makes sense. Should we add a whole new interface and a > > separate kind of listener just because global threads don't > > support restarts _y

Re: [DISCUSS] Checkstyle Import Order

Hi Dongjin, Thanks for bringing this up. I’m in favor of adding a check style rule. Thanks for testing out the alternatives. As long as we aren’t adding wildcard imports and as long as it’s easy to configure IDEs with our chosen rules, I have no preference. I assume these hold for your proposa

Re: [DISCUSS] KIP-680: TopologyTestDriver should not require a Properties argument

Hello Rohit, Thanks for picking this up! I think your KIP looks good. While I was doing some cleanup of our tests before, one thing I encountered is that, while most tests don’t semantically need to specify any configs, many tests actually do set the state directory config. They set it specific

Re: [DISCUSS] KIP-680: TopologyTestDriver should not require a Properties argument

we can tackle RocksDb directories cleanup and creating unique > directory tasks in separate KIP. > > Thanks, > Rohit > > > On Fri, Nov 6, 2020 at 7:12 AM John Roesler wrote: > > > Hello Rohit, > > > > Thanks for picking this up! I think your KIP looks goo

Re: [DISCUSS] KIP-680: TopologyTestDriver should not require a Properties argument

ms/StreamsConfig.java#L605 > >> > > >> > so > >> > I am not setting it's value explicitly in proposed no argument > >> > constructor. > >> > Does the directory have to be unique in each test? If yes, then I agree > >> >

Re: Identifying JIRA's for contribution

Hi Loknath, Thanks for your interest! Fortunately, there are many open tickets to choose from, ranging from easy to very difficult, and covering all kinds, from bugs to new features. Personally, I would suggest for you all to start with smaller-scoped projects so that you can have a lower entry

Re: Identifying JIRA's for contribution

Hi Loknath, A couple of people replied to you already. Here’s the thread: https://lists.apache.org/x/thread.html/rb93185752163fa71acfce5d11820a48f6c4551863aa3d1d98b21c0ea@%3Cdev.kafka.apache.org%3E I’m not sure what might have been wrong. Did you subscribe by following the instructions at https

Re: [VOTE] KIP-680: TopologyTestDriver should not require a Properties argument

Thanks again for the KIP, Rohit. I’m +1 (binding) Sorry, I missed your vote thread. -John On Fri, Nov 20, 2020, at 21:35, Rohit Deshpande wrote: > Thanks Guozhang. > Waiting for binding votes. > Thanks, > Rohit > > On Tue, Nov 17, 2020 at 10:13 AM Guozhang Wang wrote: > > > +1, thanks Rohi

[DISCUSS] KIP-695: Improve Streams Time Synchronization

Hello all, I'd like to propose KIP-695 to improve on the "task idling" feature we introduced in KIP-353. This KIP will allow Streams to offer deterministic time semantics in join-type topologies. For example, it makes sure that when you join two topics, that we collate the topics by timestamp. Tha

Re: [VOTE] KIP-689: Extend `StreamJoined` to allow more store configs

Sorry I missed the discussion, but I just read the KIP and the discussion. It all looks good to me. +1 (binding) -John On Thu, 2020-12-03 at 14:00 -0700, Matthias J. Sax wrote: > +1 (binding) > > On 12/3/20 11:21 AM, Guozhang Wang wrote: > > +1 (binding) > > > > Thanks Leah! > > > > On Wed, D

Re: [DISCUSS] KIP-695: Improve Streams Time Synchronization

do you mean by "too stale". Could you define > "too stale"? > > Best, > Bruno > > > On 04.12.20 23:39, John Roesler wrote: > > Hello all, > > > > I'd like to propose KIP-695 to improve on the "task idling" feature w

[VOTE] KIP-695: Improve Streams Time Synchronization

Hello all, There hasn't been much discussion on KIP-695 so far, so I'd like to go ahead and call for a vote. As a reminder, the purpose of KIP-695 to improve on the "task idling" feature we introduced in KIP-353. This KIP will allow Streams to offer deterministic time semantics in join-type topol

Re: [DISCUSS] KIP-696: Update Streams FSM to clarify ERROR state meaning

Thanks, Walker! Your proposal looks good to me. -John On Tue, 2020-12-08 at 18:29 -0800, Walker Carlson wrote: > Thanks for the feedback Guozhang! > > I clarified some of the points in the Proposed Changes section so hopefully > it will be more clear what is going on now. I also agree with your

<    4   5   6   7   8   9   10   11   12   >