Re: [DISCUSS] KIP-846: Task-level Streams metrics for bytes/records Produced

y with your > > > content and replace the heading with the next KIP number and a > > description > > > of your issue. Replace anything in italics with your own description.* > > > > > > > > > Thanks! > > > Sagar. > > > > > &g

[VOTE] KIP-846: Processor-level Streams metrics for records/bytes Producedd

Hey all, I'd like to kick off the voting thread for the KIP I proposed to add processor-level "bytes/records produced" metrics to Kafka Streams. Thanks! KIP-846: Task-level Streams metrics for bytes/records Produced

Re: [DISCUSS] KIP-846: Task-level Streams metrics for bytes/records Produced

the > specified metrics are on processor-level? > > For the rest, I am +1. > > Best, > Bruno > > On 29.05.22 00:20, John Roesler wrote: > > Thanks for the well motivated and documented KIP, Sophie! I’m in favor > of this change. > > > > -John > >

[DISCUSS] KIP-846: Task-level Streams metrics for bytes/records Produced

Hey all, I'd like to propose a very small KIP to add two metrics that will help fill a gap in the derivable produced and consumed metrics. Please take a look and reply here with any questions or concerns. KIP-846: Task-level Streams metrics for bytes/records Produced

[jira] [Created] (KAFKA-13945) Add task-level metrics to Streams for bytes/records Produced

A. Sophie Blee-Goldman created KAFKA-13945: -- Summary: Add task-level metrics to Streams for bytes/records Produced Key: KAFKA-13945 URL: https://issues.apache.org/jira/browse/KAFKA-13945

Re: [VOTE] KIP-834: Pause / Resume KafkaStreams Topologies

Thanks for the KIP! +1 (binding) On Tue, May 10, 2022, 12:24 PM Bruno Cadonna wrote: > Thanks Jim, > > +1 (binding) > > Best, > Bruno > > On 10.05.22 21:19, John Roesler wrote: > > Thanks Jim, > > > > I’m +1 (binding) > > > > -John > > > > On Tue, May 10, 2022, at 14:05, Jim Hughes wrote: > >>

Re: [DISCUSS] KIP-834: Pause / Resume KafkaStreams Topologies

) consume from input topics, b) call the > > usual commit pathways (commits will happen basically as they would have), > > and c) standBy tasks will still be processed. > > > > Shout if the KIP or those details still need some TLC. Responding to > > Sophie inline below. &g

Re: [DISCUSS] KIP-834: Pause / Resume KafkaStreams Topologies

Don't worry, I'm going to be adding the APIs for topology-level pausing as part of the modular topologies KIP, so we don't need to worry about that for now. That said, I don't think we should brush it off entirely and design this feature in a way that's going to be incompatible or hugely raise the

[jira] [Resolved] (KAFKA-13152) Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

[ https://issues.apache.org/jira/browse/KAFKA-13152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13152. Resolution: Fixed > Replace "buffered.records.per.p

[jira] [Reopened] (KAFKA-13542) Utilize the new Consumer#enforceRebalance(reason) API in Streams

[ https://issues.apache.org/jira/browse/KAFKA-13542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman reopened KAFKA-13542: Reopening this since it was reverted pending investigation into a benchmark

[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: https://issues.apache.org/jira/browse/KAFKA

[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

[jira] [Created] (KAFKA-13690) Flaky test EosIntegrationTest.shouldWriteLatestOffsetsToCheckpointOnShutdown[at_least_once]

A. Sophie Blee-Goldman created KAFKA-13690: -- Summary: Flaky test EosIntegrationTest.shouldWriteLatestOffsetsToCheckpointOnShutdown[at_least_once] Key: KAFKA-13690 URL: https://issues.apache.org/jira

Re: [DISCUSS] KIP-816: Topology changes without local state reset

Hey Nick, thanks for the KIP, this is definitely a much-needed feature. I've actually been working on a somewhat similar feature for a while now and have a good chunk of the implementation completed -- but so far it's only exposed via internal APIs and hasn't been brought to a KIP yet, as it's a

[jira] [Created] (KAFKA-13645) Support the TopologyTestDriver with modular topologies

A. Sophie Blee-Goldman created KAFKA-13645: -- Summary: Support the TopologyTestDriver with modular topologies Key: KAFKA-13645 URL: https://issues.apache.org/jira/browse/KAFKA-13645 Project

[jira] [Created] (KAFKA-13644) Support global state stores with modular topologies

A. Sophie Blee-Goldman created KAFKA-13644: -- Summary: Support global state stores with modular topologies Key: KAFKA-13644 URL: https://issues.apache.org/jira/browse/KAFKA-13644 Project

[jira] [Created] (KAFKA-13643) Replace "NamedTopology" with "ModularTopology" in the codebase

A. Sophie Blee-Goldman created KAFKA-13643: -- Summary: Replace "NamedTopology" with "ModularTopology" in the codebase Key: KAFKA-13643 URL: https://issues.apache.org/jir

Re: [DISCUSS] KIP-818: Introduce cache-size-bytes-total Task Level Metric

Hey Sagar, thanks for the KIP! And yes, all metrics are considered part of the public API and thus require a KIP to add (or modify, etc...) Although in this particular case, you could probably make a good case for just considering it as an update to the original KIP which added the analogous

[jira] [Created] (KAFKA-13590) Rename InternalTopologyBuilder's #topicGroups method to be more descriptive

A. Sophie Blee-Goldman created KAFKA-13590: -- Summary: Rename InternalTopologyBuilder's #topicGroups method to be more descriptive Key: KAFKA-13590 URL: https://issues.apache.org/jira/browse/KAFKA-13590

Re: [DISCUSS] KIP-811 Add separate delete.interval.ms to Kafka Streams

Hey Nick, I think you forgot to link to the KIP document, but I take it this is it: KIP-811: Add separate delete.interval.ms to Kafka Streams The overall proposal sounds good to me, just a few minor things: 1. Please specify everything needed to

[jira] [Created] (KAFKA-13543) Consumer may pass stale cluster metadata to the assignor following a subscription update

A. Sophie Blee-Goldman created KAFKA-13543: -- Summary: Consumer may pass stale cluster metadata to the assignor following a subscription update Key: KAFKA-13543 URL: https://issues.apache.org/jira/browse

[jira] [Created] (KAFKA-13542) Utilize the new Consumer#enforceRebalance(reason) API in Streams

A. Sophie Blee-Goldman created KAFKA-13542: -- Summary: Utilize the new Consumer#enforceRebalance(reason) API in Streams Key: KAFKA-13542 URL: https://issues.apache.org/jira/browse/KAFKA-13542

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

Would you mind filing a ticket for this? Would be nice to have it on the books so other users know we know about it, and more importantly which versions this is and is not fixed in. Thanks for the report! On Thu, Nov 18, 2021 at 6:10 AM John Roesler wrote: > Thanks for pointing that out,

Re: KIP-800: Add reason to LeaveGroupRequest

This sounds great, thanks David. One thought: what do you think about doing something similar for the JoinGroup request? When you only have broker logs and not client logs, it's somewhere between challenging and impossible to determine the reason for a rebalance that was triggered explicitly by

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

Thanks John, I've been looking forward to this for a while now. It was pretty horrifying to learn how present-day IQ works (or rather, doesn't work) with custom state stores :/ One minor cosmetic point, In the InteractiveQueryRequest class, the # getPartitions method has a return type of Set,

[jira] [Created] (KAFKA-13439) Deprecate EAGER rebalancing in Kafka Streams

A. Sophie Blee-Goldman created KAFKA-13439: -- Summary: Deprecate EAGER rebalancing in Kafka Streams Key: KAFKA-13439 URL: https://issues.apache.org/jira/browse/KAFKA-13439 Project: Kafka

[jira] [Resolved] (KAFKA-13381) Wrap all uncaught exceptions as StreamsException with TaskId field

[ https://issues.apache.org/jira/browse/KAFKA-13381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13381. Resolution: Fixed > Wrap all uncaught exceptions as StreamsExcept

[jira] [Resolved] (KAFKA-12994) Migrate all Tests to New API and Remove Suppression for Deprecation Warnings related to KIP-633

[ https://issues.apache.org/jira/browse/KAFKA-12994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12994. Resolution: Fixed > Migrate all Tests to New API and Remove Suppress

Re: [VOTE] Add TaskId field to StreamsException

s, it'll be really nice to get some information > >>>> about the context of the exception. > >>>> > >>>> Thanks! > >>>> -John > >>>> > >>>> On Mon, 2021-10-18 at 13:56 -0500, Walker Carlson wrote: >

Re: [DISCUSS] Add TaskId field to StreamsException

Ah, thanks. I've updated the KIP On Mon, Oct 18, 2021 at 3:36 PM Matthias J. Sax wrote: > Sophie, > > I think we also need to pass in a `TaskId` into the constructor, which > are also part of the public API. > > Otherwise LGTM. > > -Matthias > > On 10/17/21 9:03

[VOTE] Add TaskId field to StreamsException

Hey all, I'd like to kick off the vote on this small KIP which adds a TaskId field to the StreamsException class. Please take a look and cast your vote when you have a chance. Links: - KIP-783: Add TaskId field to StreamsException - PR

[DISCUSS] Add TaskId field to StreamsException

tps://cwiki.apache.org/confluence/x/VIlnCw> - PR #11405 <https://cwiki.apache.org/confluence/x/VIlnCw> Cheers, Sophie Blee-Goldman

[jira] [Created] (KAFKA-13381) Wrap all uncaught exceptions as StreamsException with TaskId field

A. Sophie Blee-Goldman created KAFKA-13381: -- Summary: Wrap all uncaught exceptions as StreamsException with TaskId field Key: KAFKA-13381 URL: https://issues.apache.org/jira/browse/KAFKA-13381

[jira] [Created] (KAFKA-13336) Migrate StreamsBuilder class to interface with factory method on KafkaStreams

A. Sophie Blee-Goldman created KAFKA-13336: -- Summary: Migrate StreamsBuilder class to interface with factory method on KafkaStreams Key: KAFKA-13336 URL: https://issues.apache.org/jira/browse/KAFKA-13336

[jira] [Created] (KAFKA-13333) Optimize condition for triggering rebalance after wiping out corrupted task

A. Sophie Blee-Goldman created KAFKA-1: -- Summary: Optimize condition for triggering rebalance after wiping out corrupted task Key: KAFKA-1 URL: https://issues.apache.org/jira/browse/KAFKA-1

[jira] [Resolved] (KAFKA-12486) Utilize HighAvailabilityTaskAssignor to avoid downtime on corrupted task

[ https://issues.apache.org/jira/browse/KAFKA-12486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12486. Resolution: Fixed > Utilize HighAvailabilityTaskAssignor to av

[jira] [Created] (KAFKA-13332) New pattern-matched topic with more partitions than existing matched topics can crash Kafka Streams

A. Sophie Blee-Goldman created KAFKA-13332: -- Summary: New pattern-matched topic with more partitions than existing matched topics can crash Kafka Streams Key: KAFKA-13332 URL: https://issues.apache.org

[jira] [Created] (KAFKA-13295) Long restoration times for new tasks can lead to transaction timeouts

A. Sophie Blee-Goldman created KAFKA-13295: -- Summary: Long restoration times for new tasks can lead to transaction timeouts Key: KAFKA-13295 URL: https://issues.apache.org/jira/browse/KAFKA-13295

[jira] [Created] (KAFKA-13283) Migrate experimental feature to public API

A. Sophie Blee-Goldman created KAFKA-13283: -- Summary: Migrate experimental feature to public API Key: KAFKA-13283 URL: https://issues.apache.org/jira/browse/KAFKA-13283 Project: Kafka

[jira] [Created] (KAFKA-13282) Draft final NamedTopology API and publish a KIP

A. Sophie Blee-Goldman created KAFKA-13282: -- Summary: Draft final NamedTopology API and publish a KIP Key: KAFKA-13282 URL: https://issues.apache.org/jira/browse/KAFKA-13282 Project: Kafka

[jira] [Created] (KAFKA-13281) Support upgrades with dynamic addition/removal of disjoint "named" topologies

A. Sophie Blee-Goldman created KAFKA-13281: -- Summary: Support upgrades with dynamic addition/removal of disjoint "named" topologies Key: KAFKA-13281 URL: https://issues.apache.org/jira/browse/K

Re: [DISCUSS] KIP-770: Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

Oh you already did -- missed the VOTE thread somehow. Voted :) On Tue, Sep 7, 2021 at 6:27 PM Sophie Blee-Goldman wrote: > Yeah, feel free to kick off the vote > > On Thu, Sep 2, 2021 at 6:08 AM Sagar wrote: > >> Thanks Guozhang and Luke. >> >> I have updated

Re: [VOTE] KIP-770: Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

+1 (binding) Thanks for the KIP! -Sophie On Tue, Sep 7, 2021 at 1:59 PM Guozhang Wang wrote: > Thanks Sagar, +1 from me. > > > Guozhang > > On Sat, Sep 4, 2021 at 10:29 AM Sagar wrote: > > > Hi All, > > > > I would like to start a vote on the following KIP: > > > > >

Re: [DISCUSS] KIP-770: Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

ozhang and Sophie. > > > > > > > > Yeah a small default value would lower the throughput. I didn't quite > > > > realise it earlier. It's slightly hard to predict this value so I > would > > > > guess around 1/2 GB to 1 GB? WDYT? > > > >

Re: [DISCUSS] KIP-770: Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

1) I agree that we should just distribute the bytes evenly, at least for now. It's simpler to understand and we can always change it later, plus it makes sense to keep this aligned with how the cache works today 2) +1 to being conservative in the generous sense, it's just not something we can

[jira] [Resolved] (KAFKA-13128) Flaky Test StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread

[ https://issues.apache.org/jira/browse/KAFKA-13128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13128. Resolution: Fixed > Flaky T

[jira] [Resolved] (KAFKA-12963) Improve error message for Class cast exception

[ https://issues.apache.org/jira/browse/KAFKA-12963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12963. Fix Version/s: 3.1.0 Resolution: Fixed > Improve error mess

[jira] [Resolved] (KAFKA-8734) Remove PartitionAssignorAdapter and deprecated PartitionAssignor interface

[ https://issues.apache.org/jira/browse/KAFKA-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-8734. --- Fix Version/s: 3.0.0 Resolution: Fixed > Rem

Re: [VOTE] KIP-633: Drop 24 hour default of grace period in Streams

d, Jun 16, 2021 at 7:54 PM Matthias J. Sax > wrote: > > > >> Quick follow up. I did a small update to the KIP with regard to > >> https://issues.apache.org/jira/browse/KAFKA-12909 > >> > >> Israel, Sophie, and Guozhang did agree to this change. I don't

[jira] [Created] (KAFKA-13217) Reconsider skipping the LeaveGroup on close() or add an overload that does so

A. Sophie Blee-Goldman created KAFKA-13217: -- Summary: Reconsider skipping the LeaveGroup on close() or add an overload that does so Key: KAFKA-13217 URL: https://issues.apache.org/jira/browse/KAFKA-13217

Re: [DISCUSS] KIP-759: Unneeded repartition canceling

marter' code (the decision is taken > >> depending on metadata provided for all the upstream mappings), 3) > >> overall safer for the user. > >> > >> Arguments against: invasive KStreams API change, 5 more method > >> overloads. Further on, when we

Re: [DISCUSS] KIP-759: Unneeded repartition canceling

o change > the overall topology. > > By the way, if we later find a better solution, it's way more easy to > deprecate a single `markAsPartitioned` operation than 5 method overloads. > > What do you think? > > > > > 04.08.2021 4:23, Sophie Blee-Goldman пишет: > &g

[jira] [Reopened] (KAFKA-13128) Flaky Test StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread

[ https://issues.apache.org/jira/browse/KAFKA-13128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman reopened KAFKA-13128: Assignee: (was: A. Sophie Blee-Goldman) Failed again

[jira] [Created] (KAFKA-13170) Flaky Test InternalTopicManagerTest.shouldRetryDeleteTopicWhenTopicUnknown

A. Sophie Blee-Goldman created KAFKA-13170: -- Summary: Flaky Test InternalTopicManagerTest.shouldRetryDeleteTopicWhenTopicUnknown Key: KAFKA-13170 URL: https://issues.apache.org/jira/browse/KAFKA-13170

[jira] [Created] (KAFKA-13169) Flaky Test QueryableStateIntegrationTest.shouldBeAbleToQueryStateWithNonZeroSizedCache

A. Sophie Blee-Goldman created KAFKA-13169: -- Summary: Flaky Test QueryableStateIntegrationTest.shouldBeAbleToQueryStateWithNonZeroSizedCache Key: KAFKA-13169 URL: https://issues.apache.org/jira/browse

Re: [DISCUSS] KIP-759: Unneeded repartition canceling

Do we really need a whole DSL operator for this? I think the original name for this operator -- `cancelRepartition()` -- is itself a sign that this is not an operation on the stream itself but rather a command/request to whichever operator would have otherwise triggered this repartition. What

[jira] [Resolved] (KAFKA-10246) AbstractProcessorContext topic() throws NullPointerException when modifying a state store within the DSL from a punctuator

[ https://issues.apache.org/jira/browse/KAFKA-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-10246. Resolution: Fixed > AbstractProcessorContext topic() thr

Re: [VOTE] KIP-761: Add Total Blocked Time Metric to Streams

Thanks for updating the KIP, +1 (binding) -Sophie On Tue, Jul 27, 2021 at 9:57 AM Guozhang Wang wrote: > Hello Rohan, > > Thanks for the KIP. As Bruno mentioned in the other thread could you update > the "New Metrics" that 1) we have sub-titles for streams, producer, > consumer metrics, just

[jira] [Resolved] (KAFKA-13150) How is Kafkastream configured to consume data from a specified offset ？

[ https://issues.apache.org/jira/browse/KAFKA-13150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13150. Resolution: Invalid > How is Kafkastream configured to consume data f

Re: [DISCUSS] KIP-761: Add total blocked time metric to streams

Thanks for the clarifications, that all makes sense. I'm ready to vote on the KIP, but can you just update the KIP first to address Bruno's feedback? Ie just fix the tags and fill in the missing fields. For example it sounds like these would be thread-level metrics. You should be able to figure

[jira] [Resolved] (KAFKA-13021) Improve Javadocs for API Changes and address followup from KIP-633

[ https://issues.apache.org/jira/browse/KAFKA-13021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13021. Resolution: Fixed > Improve Javadocs for API Changes and address follo

Re: [DISCUSS] KIP-765: Introduce new SlidingWindow type for [start,end] time

@Matthias that operator doesn't need to be deprecated/updated as the argument to it is a SlidingWindow*s*, not a SlidingWindow (which is what this KIP is proposing to add). The SlidingWindows class which is part of the public API is really just a config container class, it doesn't hold the actual

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

zed > > > > > > > > > > > > right > > > > > > > > > > > > > > > after > > > > > > > > > > > > > > > > > > > Feature Freeze. > > > > > > > > > > > > > > > > > &

[jira] [Created] (KAFKA-13128) Flaky Test StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread

A. Sophie Blee-Goldman created KAFKA-13128: -- Summary: Flaky Test StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread Key: KAFKA-13128 URL: https://issues.apache.org/jira/browse

[jira] [Created] (KAFKA-13126) Overflow in joinGroupTimeoutMs when max.poll.interval.ms is MAX_VALUE leads to missing rebalances

A. Sophie Blee-Goldman created KAFKA-13126: -- Summary: Overflow in joinGroupTimeoutMs when max.poll.interval.ms is MAX_VALUE leads to missing rebalances Key: KAFKA-13126 URL: https://issues.apache.org

Re: [DISCUSS] KIP-761: Add total blocked time metric to streams

Hey Rohan, The current metrics proposed in the KIP all LGTM, but if the goal is to include *all* time spent blocking on any client API then there are a few that might need to be added to this list. For example Consumer#committed is called in StreamTask to get the offsets during initialization,

[jira] [Created] (KAFKA-13121) Flaky Test TopicBasedRemoteLogMetadataManagerTest.testNewPartitionUpdates()

A. Sophie Blee-Goldman created KAFKA-13121: -- Summary: Flaky Test TopicBasedRemoteLogMetadataManagerTest.testNewPartitionUpdates() Key: KAFKA-13121 URL: https://issues.apache.org/jira/browse/KAFKA-13121

[jira] [Created] (KAFKA-13096) QueryableStoreProvider is not updated when threads are added/removed/replaced rendering IQ impossible

A. Sophie Blee-Goldman created KAFKA-13096: -- Summary: QueryableStoreProvider is not updated when threads are added/removed/replaced rendering IQ impossible Key: KAFKA-13096 URL: https://issues.apache.org

[jira] [Resolved] (KAFKA-12896) Group rebalance loop caused by repeated group leader JoinGroups

[ https://issues.apache.org/jira/browse/KAFKA-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12896. Resolution: Fixed > Group rebalance loop caused by repeated group lea

[jira] [Created] (KAFKA-13081) Port sticky assignor fixes (KAFKA-12984) back to 2.8

A. Sophie Blee-Goldman created KAFKA-13081: -- Summary: Port sticky assignor fixes (KAFKA-12984) back to 2.8 Key: KAFKA-13081 URL: https://issues.apache.org/jira/browse/KAFKA-13081 Project

[jira] [Resolved] (KAFKA-13075) Consolidate RocksDBStoreTest and RocksDBKeyValueStoreTest

[ https://issues.apache.org/jira/browse/KAFKA-13075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-13075. Fix Version/s: 3.1.0 Resolution: Fixed > Consolid

[jira] [Created] (KAFKA-13075) Consolidate RocksDBStore and RocksDBKeyValueStoreTest

A. Sophie Blee-Goldman created KAFKA-13075: -- Summary: Consolidate RocksDBStore and RocksDBKeyValueStoreTest Key: KAFKA-13075 URL: https://issues.apache.org/jira/browse/KAFKA-13075 Project

[jira] [Created] (KAFKA-12993) Formatting of Streams 'Memory Management' docs is messed up

A. Sophie Blee-Goldman created KAFKA-12993: -- Summary: Formatting of Streams 'Memory Management' docs is messed up Key: KAFKA-12993 URL: https://issues.apache.org/jira/browse/KAFKA-12993

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

/ connect users. But this may also be where the > > feature has the most benefit due to expensive setup/teardown during > > rebalance, and stop-the-world can be less of a concern for many "regular > > consumers". > > > > This is probably irrelevant here,

[jira] [Created] (KAFKA-12984) Cooperative sticky assignor can get stuck with invalid SubscriptionState input metadata

A. Sophie Blee-Goldman created KAFKA-12984: -- Summary: Cooperative sticky assignor can get stuck with invalid SubscriptionState input metadata Key: KAFKA-12984 URL: https://issues.apache.org/jira/browse

[jira] [Created] (KAFKA-12983) onJoinPrepare is not always invoked before joining the group

A. Sophie Blee-Goldman created KAFKA-12983: -- Summary: onJoinPrepare is not always invoked before joining the group Key: KAFKA-12983 URL: https://issues.apache.org/jira/browse/KAFKA-12983

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

Guozhang did agree to this change. I don't think we > need to re-vote. > > Please let us know if there are any concerns. > > > -Matthias > > On 1/27/21 12:48 PM, Sophie Blee-Goldman wrote: > > Thanks Bruno, that sounds like a good addition. +1 > > > > O

[jira] [Created] (KAFKA-12936) In-memory stores are always restored from scratch after dropping out of the group

A. Sophie Blee-Goldman created KAFKA-12936: -- Summary: In-memory stores are always restored from scratch after dropping out of the group Key: KAFKA-12936 URL: https://issues.apache.org/jira/browse/KAFKA

[jira] [Resolved] (KAFKA-12920) Consumer's cooperative sticky assignor need to clear generation / assignment data upon `onPartitionsLost`

[ https://issues.apache.org/jira/browse/KAFKA-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12920. Resolution: Not A Bug > Consumer's cooperative sticky assignor n

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

> > > > > On Fri, Apr 16, 2021 at 2:33 PM Guozhang Wang > > > > wrote: > > > > > > > > > > > 1) From user's perspective, it is always possible that a commit > > > within > > > > > > onPa

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

t least try our best > to see if we can make it into V3.0 since cooperative rebalancing is a major > improvement. I'll kick off a vote later. > > Thank you. > Luke > > On Thu, Jun 3, 2021 at 7:08 AM Sophie Blee-Goldman > wrote: > > > Hey Luke, > > > > It's

Re: [VOTE] KIP-726: Make the "cooperative-sticky, range" as the default assignor

+1 (binding) Thanks Luke On Mon, Jun 7, 2021 at 3:26 AM Luke Chen wrote: > Hi Ismael, > Thanks for your comments. I updated the KIP for the "Compatibility, Upgrade > path" section. > Simply put, no special upgrade path is necessary. > > Thank you. > Luke > > > On Mon, Jun 7, 2021 at 4:16 PM

Re: [VOTE] KIP-744: Migrate TaskMetadata and ThreadMetadata to an interface with internal implementation

Thanks for the KIP! +1 (binding) -Sophie On Mon, Jun 7, 2021 at 11:19 AM Guozhang Wang wrote: > Thanks, that update LGTM. +1! > > Guozhang > > On Mon, Jun 7, 2021 at 9:45 AM Josep Prat > wrote: > > > Hi Guozhang, > > Let me know if the updated KIP meets your requests. And thanks again for > >

Re: [VOTE] KIP-334 - Include partitions in exceptions raised during consumer record deserialization/validation

Thanks for the KIP +1 (binding) - Sophie On Wed, Jun 2, 2021 at 3:43 PM Matthias J. Sax wrote: > +1 (binding) > > On 6/2/21 2:34 PM, Colin McCabe wrote: > > +1 (binding) > > > > Thanks, Sarwar. > > > > best, > > Colin > > > > On Wed, Jun 2, 2021, at 13:29, Sarwar Bhuiyan wrote: > >> Thanks

Re: [DISCUSS] KIP-726: Make the CooperativeStickyAssignor as the default assignor

t; > 2) That's crystal, thank you for the clarification. > > On Wed, Apr 14, 2021 at 6:46 PM Sophie Blee-Goldman > wrote: > > > 1) Once the short-circuit is triggered, the member will downgrade to the > > EAGER protocol, but > > won't necessarily try to rejoin the group

Re: [DISCUSS] KIP-744: Migrate TaskMetadata to interface with internal implementation

Thanks for the KIP! I'm on board with the overall proposal, just a few comments: 1) The motivation section says TaskMetadata should have never been a class available for the general > public, but more of an internal class which is a bit misleading as it seems to imply that TaskMetadata itself

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

Ah ok, thanks Konstantine. I won't bug you about every new KIP that comes in between now and KIP Freeze :P +1 on the scheduling changes as well On Wed, May 26, 2021 at 4:00 PM David Arthur wrote: > The new schedule looks good to me, +1 > > On Wed, May 26, 2021 at 6:29 PM Ismael Juma wrote: >

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

Hey Konstantine, I did a quick skim over the Streams KIPs and found two more which had not been moved to the "Adopted" section on the main KIP page and are missing from the release notes. These are: - KIP-466: Add support for List serialization and deserialization

[jira] [Created] (KAFKA-12851) Flaky Test RaftEventSimulationTest.canMakeProgressIfMajorityIsReachable

A. Sophie Blee-Goldman created KAFKA-12851: -- Summary: Flaky Test RaftEventSimulationTest.canMakeProgressIfMajorityIsReachable Key: KAFKA-12851 URL: https://issues.apache.org/jira/browse/KAFKA-12851

[jira] [Created] (KAFKA-12849) Consider migrating TaskMetadata to interface with internal implementation

A. Sophie Blee-Goldman created KAFKA-12849: -- Summary: Consider migrating TaskMetadata to interface with internal implementation Key: KAFKA-12849 URL: https://issues.apache.org/jira/browse/KAFKA-12849

[jira] [Created] (KAFKA-12848) Add some basic benchmarks for Kafka Streams

A. Sophie Blee-Goldman created KAFKA-12848: -- Summary: Add some basic benchmarks for Kafka Streams Key: KAFKA-12848 URL: https://issues.apache.org/jira/browse/KAFKA-12848 Project: Kafka

[jira] [Reopened] (KAFKA-9295) KTableKTableForeignKeyInnerJoinMultiIntegrationTest#shouldInnerJoinMultiPartitionQueryable

[ https://issues.apache.org/jira/browse/KAFKA-9295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman reopened KAFKA-9295: --- Guess there is still something else going on here yet. At this point I think we

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

+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 at 1:51 PM Leah Thomas > wrote: > > > Hi, > > > > I'd like to kick-off voting for KIP-741: Change default serde to be null. > > < >

[jira] [Created] (KAFKA-12844) KIP-740 follow up: clean up TaskId

A. Sophie Blee-Goldman created KAFKA-12844: -- Summary: KIP-740 follow up: clean up TaskId Key: KAFKA-12844 URL: https://issues.apache.org/jira/browse/KAFKA-12844 Project: Kafka Issue

[jira] [Created] (KAFKA-12843) KIP-740 follow up: clean up TaskMetadata

A. Sophie Blee-Goldman created KAFKA-12843: -- Summary: KIP-740 follow up: clean up TaskMetadata Key: KAFKA-12843 URL: https://issues.apache.org/jira/browse/KAFKA-12843 Project: Kafka

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

+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 like to start a vote on KIP-743 that proposes to remove config value > > 0.10.0-2.4 from Streams config

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

I agree with John's assessment -- if I'm interpreting it correctly, otherwise I'll claim this idea as my own :P -- that we can just drop it in 3.0 as it was effectively deprecated since day 1, ie version 2.5. In addition to what John said about this not being the default, I'll note that we never

[jira] [Resolved] (KAFKA-12779) TaskMetadata should return actual TaskId rather than plain String

[ https://issues.apache.org/jira/browse/KAFKA-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] A. Sophie Blee-Goldman resolved KAFKA-12779. Resolution: Fixed > TaskMetadata should return actual TaskId rather t

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

t name, but I knew since this is not favored by most people :). > > > > > > On Wed, May 19, 2021 at 11:01 PM Guozhang Wang > wrote: > > > > > > > Thanks Sophie, I like the current proposal better compared to adding > a new > > > >

<    1   2   3   4   5   6   7   8   9   >