[jira] [Created] (KAFKA-13713) Tech Debt: keep StreamThread and TopologyMetadata's view of the topology in sync

A. Sophie Blee-Goldman created KAFKA-13713: -- Summary: Tech Debt: keep StreamThread and TopologyMetadata's view of the topology in sync Key: KAFKA-13713 URL:

[jira] [Created] (KAFKA-13712) Make topology addition/removal atomic so we can roll back if request fails

A. Sophie Blee-Goldman created KAFKA-13712: -- Summary: Make topology addition/removal atomic so we can roll back if request fails Key: KAFKA-13712 URL: https://issues.apache.org/jira/browse/KAFKA-13712

[jira] [Created] (KAFKA-13711) Fix bugs with input topic management to support pattern subscription fully

A. Sophie Blee-Goldman created KAFKA-13711: -- Summary: Fix bugs with input topic management to support pattern subscription fully Key: KAFKA-13711 URL: https://issues.apache.org/jira/browse/KAFKA-13711

Re: [DISCUSS] KIP-824 Allowing dumping segmentlogs limiting the batches in the output

Hi Sergio, Thanks for your explanation. Make sense to me. > Only interesting thing that I have just found is *max-message-size *is not used while dump logs are requested, instead it is used by dumpIndex Are you interested in expanding the scope of this KIP to include the *max-message-size* in

Re: [VOTE] 3.0.1 RC0

+1 (non-binding). I used the staged Scala 2.13 binaries and the staging Maven repository to run my tests. All seems to work fine, no issues found. Thanks Jakub On Thu, Mar 3, 2022 at 7:05 PM Mickael Maison wrote: > Hello Kafka users, developers and client-developers, > > This is the first

Re: [DISCUSS] KIP-824 Allowing dumping segmentlogs limiting the batches in the output

hey Luke, Let me answer them: 1. If the *max-batches-size* is too small that results in no records output, will we output any information to the user? If the *max-batches-size*is even smaller than the first batch then there won't be any output, this is handled by FileRecords class, I think this

Re: [DISCUSS] KIP-824 Allowing dumping segmentlogs limiting the batches in the output

hey Kirk, Thanks for the questions, please let me answer them: 1. This is handled by the *FileRecords class, *now the open uses the slice which takes care of the end

Re: [DISCUSS] KIP-820: Extend KStream process with new Processor API

Hello all, It seems like we're making good progress on this discussion. If I'm keeping track correctly, if we can resolve this question about how to handle processValues(), then we should be able to finalize the vote, right? I share Matthias's preference for having a type-safe API. Just as a

Re: [DISCUSS] KIP-820: Extend KStream process with new Processor API

Matthias, thanks for your feedback. I can see the following alternatives to deal with `processValues()`: 1. Runtime key validation (current proposal) 2. Using Void type. Guozhang already points out some important considerations about allocating `Record` twice. 3. Adding a new ValueRecord,