you!
> <https://cwiki.apache.org/confluence/x/QAq9F>
>
> Best Regards,
> Jiunn-Yang
>
> > Sophie Blee-Goldman 於 2025年4月26日 下午1:34 寫道：
> >
> > That's a good point about the DEFAULT enum, it would essentially be
> > redundant with REMAIN_IN_GROUP since
Looks great, +1 (binding)
On Mon, Apr 28, 2025 at 4:47 AM Herman K. Jakobsen <
hermankjakob...@gmail.com> wrote:
> Hi,
> I would like to start a vote on KIP-1146: Anchored punctuation - Apache
> Kafka - Apache Software Foundation
> <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1146%3A
於 2025年4月26日 週六 上午11:34寫道：
> >
> > > Hello Sophie, Mathias,
> > >
> > > Thanks for your comments.
> > >
> > > I fully agree with option 2 and will proceed to update the KIP to
> reflect
> > > this choice.
> > >
> > > Bes
Options withTimeout(Duration);
>public CloseOptions withLeaveGroup(boolean);
> }
>
> (Or similar names.)
>
> Btw: Instead of using a `boolean` it could also be beneficial to use an
> enum a la KIP-1092 with valued DEFAULT, LEAVE_GROUP, REMAIN_IN_GROUP?
>
>
>
o Sophie,
>
> Thanks for your comments,
>
> I’ve updated the KIP to add a new static `build()` method for initializing
> the CloseOptions object.
> The public constructor has been deprecated, while the existing
> fluent-style methods remain unchanged.
>
> Best Regards,
> J
Thanks for the KIP!
This looks good but a few comments about the API: I think we actually want
more of a fluent pattern than a literal builder pattern, to be consistent
with other APIs in Kafka Streams. You can criticize Matthias for saying
"builder pattern" in the ticket, he means a fluent style
t if we weren't going to remove them then we should just go
ahead and un-deprecate them...or something like that (#10484
<https://github.com/apache/kafka/pull/10484>). So...if there was no KIP to
un-deprecate them, can we re-deprecate them without a KIP?
On Wed, Apr 2, 2025 at 10:02 PM
erties+instead+of+StreamsConfig+in+KafkaStreams+constructor
> > [2]
> >
> >
> https://github.com/apache/kafka/blob/b9d5597b445741330bf561b096c25e28224988eb/clients/src/main/java/org/apache/kafka/clients/consumer/KafkaConsumer.java#L600
> >
> > On 26.03.25 22:33
Thanks for the KIP!
I pretty much echo what Matthias has said so far regarding the API.
Regarding #4-5, assuming we would just be leaving out stream-time in the
initial implementation for time/scope reasons and might want to add this in
the future, I think it's best to just throw an exception if
s instead of the simple data type. This
> seems pretty inconsistent for the interfaces of a single open source
> project.
>
> Cheers,
> Lucas
>
> On Fri, Mar 14, 2025 at 2:43 AM Sophie Blee-Goldman
> wrote:
> >
> > I don't believe it's possible to on
only passing StreamsConfig objects to
> > the constructors. The reason is that Map/Properties are mutable and
> > StreamsConfig is immutable. IMO, it would be safer to pass immutable
> > configs to the constructors. But maybe there is a good reason to pass
> > mutable configs th
[
https://issues.apache.org/jira/browse/KAFKA-13281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13281.
Resolution: Won't Do
> Support live upgrades with dynamic
Thanks for the KIP! The proposal here sounds like the right direction to go
in for me, but I'll be interested to hear what others think.
I'm wondering if we should offer additional StreamsBuilder & Topology
constructors that accept a plain config map (or Properties) alongside the
StreamsConfig con
ka Streams requires broker compatibility considerations,
> see: [Streams API Broker Compatibility](
> https://kafka.apache.org/39/documentation/streams/upgrade-guide#streams_api_broker_compat
> )
> > >>>
> > >>> The above approach simplifies the definition of the bridge
Thanks David! This is awesome, really glad to see this effort to reduce
test flakiness.
One question -- are tests automatically sorted into these buckets or do we
have to manually move them? And if so, how does that work (eg a test in
"main" becomes flaky)
On Tue, Feb 25, 2025 at 3:20 PM David Ar
whew, long response from Matthias :P Lot to digest but I want to add
on/respond to a few points:
If they want to be "advantageous", they could make it a two step upgrade
> I guess, and go from 2.5 (or older) directly to 3.x and apply all
> required code changes in a single upgrade step, and repea
[
https://issues.apache.org/jira/browse/KAFKA-18840?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18840.
Resolution: Invalid
Closing this as invalid – after further inspection it
A. Sophie Blee-Goldman created KAFKA-18840:
--
Summary: Add system test for 2-rolling-bounce bridge release
upgrade path in Streams
Key: KAFKA-18840
URL: https://issues.apache.org/jira/browse/KAFKA-18840
A. Sophie Blee-Goldman created KAFKA-18839:
--
Summary: Drop support for eager rebalancing in Streams
Key: KAFKA-18839
URL: https://issues.apache.org/jira/browse/KAFKA-18839
Project: Kafka
One minor suggestion: use BatchWindows instead of BatchedWindows. The
version without the "ed" matches up with the established naming pattern and
grammar used by other Windows classes: eg TimeWindows, SessionWindows,
SlidingWindows
Not a big deal though, won't redact my +1 on the voting thread if
+1 (binding)
Thanks for the KIP! Neat and practical idea
On Tue, Feb 4, 2025 at 10:52 AM Almog Gavra wrote:
> Hello All,
>
> I'd like to start a vote on KIP-1127. Please take a look at the KIP and
> Discussion thread and let me know what you think.
>
> Note that the discussion thread was incorr
hat you've
> loaded from the build cache and your PR -- Gradle should skip that task
> (you'll see FROM-CACHE in the output).
>
> Hope this helps!
> -David A
>
> On Wed, Jan 22, 2025 at 8:42 PM Sophie Blee-Goldman >
> wrote:
>
> > >
> > >
Infra that merge queues will be available soon. In
> light of this, I'm going to expand this proposal into a KIP that includes
> merge queues. Stay tuned
>
> -David A
>
> On Wed, Jan 22, 2025 at 6:37 PM Sophie Blee-Goldman >
> wrote:
>
> > David, just to
David, just to make sure I understand, are you saying this will help with
the actual test runtime, or only the compile time of the build? Just
wondering because I've personally never found the compile times to be a
roadblock, since the test times are so long. If this change only speeds up
compiling
Thanks for the KIP. I'm all for documenting the upgrade path like this.
Just want to chime in on the Streams side of things, since there is (at
least) one nuance which is probably worth accounting for:
Because of the introduction of cooperative rebalancing in 2.4 which was
enabled by default for K
[
https://issues.apache.org/jira/browse/KAFKA-14419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-14419.
Assignee: A. Sophie Blee-Goldman
Resolution: Duplicate
> Fai
tl;dr:
1) I tend to agree we should keep the existing behavior, but what this
means is actually different and more complicated than just "if leaves
group, then invokes leave callback"
2) Personally I think we should actually *always* invoke this callback, for
every case
Longer version:
First, to
[
https://issues.apache.org/jira/browse/KAFKA-18326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18326.
Fix Version/s: 4.0.0
3.9.1
3.8.2
[
https://issues.apache.org/jira/browse/KAFKA-18026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18026.
Resolution: Fixed
> Allow custom processor wrapp
+1 (binding)
thanks Sebastien!
-Sophie
On Tue, Dec 10, 2024 at 9:26 AM Bill Bejeck wrote:
> Hi Sébastien,
>
> Thanks for the KIP!
>
> +1(binding)
>
> Regards,
> Bill
>
> On Fri, Dec 6, 2024 at 4:33 AM Bruno Cadonna wrote:
>
> > Hi Sébastien,
> >
> > +1 (binding)
> >
> > Many Thanks!
> > Bruno
t;>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 26, 2024 at 9:37 PM Sebastien Viale
> >>>>> wrote:
> >>>>>>
> >>>>>> Thanks Bruno for your comments:
> >>>>>>
> >>>>>
[
https://issues.apache.org/jira/browse/KAFKA-13713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13713.
Resolution: Won't Fix
> Tech Debt: keep StreamTh
[
https://issues.apache.org/jira/browse/KAFKA-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13282.
Resolution: Won't Fix
> Draft final NamedTopology API and publi
[
https://issues.apache.org/jira/browse/KAFKA-13645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13645.
Resolution: Won't Fix
> Support the TopologyTestDriver with
[
https://issues.apache.org/jira/browse/KAFKA-13644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13644.
Resolution: Won't Fix
> Support global state stores with
[
https://issues.apache.org/jira/browse/KAFKA-13283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13283.
Resolution: Won't Fix
> Migrate experimental feature to pu
[
https://issues.apache.org/jira/browse/KAFKA-13643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13643.
Resolution: Won't Fix
> Replace "NamedTopology" with &q
[
https://issues.apache.org/jira/browse/KAFKA-13712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13712.
Resolution: Won't Fix
> Make topology addition/removal atomic s
[
https://issues.apache.org/jira/browse/KAFKA-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-12648.
Resolution: Won't Fix
Deprecated named topologies in 4.0 wit
[
https://issues.apache.org/jira/browse/KAFKA-13711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-13711.
Resolution: Won't Fix
> Fix bugs with input topic management to
A. Sophie Blee-Goldman created KAFKA-18196:
--
Summary: Reuse window store for stream-stream self-join
Key: KAFKA-18196
URL: https://issues.apache.org/jira/browse/KAFKA-18196
Project: Kafka
A. Sophie Blee-Goldman created KAFKA-18195:
--
Summary: Enter "incompatible" instead of leaving incompatible
entires blank in Kafka Streams broker compatibility matrix
Key: KAFKA-18195
+1 (binding)
Thank you guys for the deep discussion and for carefully considering all
the details of this new protocol. Looking forward to seeing the KIP in
action!
-Sophie
On Fri, Dec 6, 2024 at 5:52 AM Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:
> Hi Bruno and Lucas,
> Thanks
[
https://issues.apache.org/jira/browse/KAFKA-18067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18067.
Resolution: Fixed
> Kafka Streams can leak Producer client under
A. Sophie Blee-Goldman created KAFKA-18191:
--
Summary: StreamJoined name is not used for processor names
Key: KAFKA-18191
URL: https://issues.apache.org/jira/browse/KAFKA-18191
Project: Kafka
A. Sophie Blee-Goldman created KAFKA-18190:
--
Summary: TopologyTestDriver time is not synchronized with test
topics
Key: KAFKA-18190
URL: https://issues.apache.org/jira/browse/KAFKA-18190
A. Sophie Blee-Goldman created KAFKA-18067:
--
Summary: Kafka Streams can leak Producer client under EOS
Key: KAFKA-18067
URL: https://issues.apache.org/jira/browse/KAFKA-18067
Project: Kafka
A. Sophie Blee-Goldman created KAFKA-18066:
--
Summary: Misleading/mismatched StreamThread id in logging
Key: KAFKA-18066
URL: https://issues.apache.org/jira/browse/KAFKA-18066
Project: Kafka
First off, thanks for the KIP! I think this is a great idea as it's super
easy to miss naming one thing and end up with a topology that isn't
upgradeable.
A1. I actually had the same reaction as Almog to the name, I feel it's
slightly clearer as a positive instead of a negative, though I think the
Lucas Brutschy
> > wrote:
> >>
> >> Thanks!
> >>
> >> +1 (binding)
> >>
> >> Lucas
> >>
> >> Bill Bejeck schrieb am Di., 19. Nov. 2024, 00:06:
> >>
> >>> Thanks for the KIP, Sophie, seems like a us
and its two subtasks describe the proposed
improvements. One covers what we can do without the KIP to help things
ASAP, the other covers the API cleanup that will require a KIP
On Wed, Nov 20, 2024 at 5:07 PM Sophie Blee-Goldman
wrote:
> Bruno -- I updated the javadocs to remove the wrapping requ
A. Sophie Blee-Goldman created KAFKA-18054:
--
Summary: Automatically detect missed configs needed by a topology
Key: KAFKA-18054
URL: https://issues.apache.org/jira/browse/KAFKA-18054
Project
A. Sophie Blee-Goldman created KAFKA-18055:
--
Summary: Remove TopologyConfig and clean up
Topology/StreamsBuilder config APIs
Key: KAFKA-18055
URL: https://issues.apache.org/jira/browse/KAFKA-18055
A. Sophie Blee-Goldman created KAFKA-18053:
--
Summary: Clean up TopologyConfig and API for supplying configs
needed by the topology
Key: KAFKA-18053
URL: https://issues.apache.org/jira/browse/KAFKA-18053
ote:
>
> > Hi Sophie,
> >
> > Thanks for the details!
> >
> > Yeah, I think replacing the contract in the javadocs with a warning is
> > better.
> >
> > Best,
> > Bruno
> >
> > On 20.11.24 10:05, Sophie Blee-Goldman wrote:
>
[
https://issues.apache.org/jira/browse/KAFKA-18044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-18044.
Resolution: Not A Problem
> Test ticket for IN
whether the topology_epoch & topology match the
> broker-side. All following heartbeats don't include the topology
> anymore, but we do not need to "reverify" that the topology epoch &
> topology are consistent, it is enough to compare epochs.
>
> Cheers,
&g
>
> > I'm a bit confused since the motivation promises a cleanup of
> > topologyconfig/streams config, but this doesn't seem to be part of this
> > kip. But on the whole, this change looks fine for me.
> >
> > Thanks for the KIP!
> >
> > Cheers,
&
gt; > idea to specify it in the configuration.
> >
> > Cheers,
> > Nick
> >
> > On Sat, 16 Nov 2024 at 17:59, Nick Telford
> wrote:
> >
> > > Hey everyone,
> > >
> > > With respect to Bruno's proposal, could instances cache thei
7;m a bit confused since the motivation promises a cleanup of
> topologyconfig/streams config, but this doesn't seem to be part of this
> kip. But on the whole, this change looks fine for me.
>
> Thanks for the KIP!
>
> Cheers,
> Lucas,
>
> Sophie Blee-Goldm
[
https://issues.apache.org/jira/browse/KAFKA-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman reopened KAFKA-10409:
> Refactor Kafka Streams RocksDb iterat
[
https://issues.apache.org/jira/browse/KAFKA-10409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
A. Sophie Blee-Goldman resolved KAFKA-10409.
Resolution: Incomplete
> Refactor Kafka Streams RocksDb iterat
of configs.
I have made this change in the KIP so please take a look and let me know if
you have any concerns. Happy to discuss alternatives
On Mon, Nov 18, 2024 at 3:27 PM Sophie Blee-Goldman
wrote:
> Thanks Almog! That makes sense to me, I've updated the KIP so that the
> ProcessorW
s like application.id (e.g. for emitting custom metrics per
> processor).
>
> - Almog
>
> On Fri, Nov 15, 2024 at 10:16 PM Sophie Blee-Goldman <
> sop...@responsive.dev>
> wrote:
>
> > Hey all,
> >
> > We have a short KIP we'd like to propose which w
Since there have been no concerns about this proposal I'm going to go ahead
and call for a vote on KIP-1112: allow custom processor wrapping.
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1112%3A+allow+custom+processor+wrapping
Please direct any new feedback (if any) to the [DISCUSS] thre
Hey all,
We have a short KIP we'd like to propose which will allow injecting custom
code modules around the processors of Kafka Streams applications, including
DSL-built topologies.
Please let us know if you have any thoughts or concerns
https://cwiki.apache.org/confluence/display/KAFKA/KIP-111
A. Sophie Blee-Goldman created KAFKA-18026:
--
Summary: Allow custom processor wrapping
Key: KAFKA-18026
URL: https://issues.apache.org/jira/browse/KAFKA-18026
Project: Kafka
Issue
rom a classic group. A consequence of the merge
> >> is that the heartbeat now needs permissions to create and describe
> >> topics which before only the initialize call had. But we think that is
> >> not a big deal. A consumer of a Streams client will send the me
It seems like the "Create KIP" button on the main KIP page actually does
not point to this template? I was actually surprised to hear that we had a
"Documentation Plan" section already because I have literally never seen
it.
I took a quick look at this button but as far as I can tell it's pointing
+1 (binding)
thanks Bill
On Wed, Nov 6, 2024 at 4:44 PM Matthias J. Sax wrote:
> +1 (binding)
>
> On 11/6/24 3:39 AM, Apoorv Mittal wrote:
> > Hi Bill,
> > Thanks for the KIP.
> >
> > +1 (non-binding)
> >
> > Regards,
> > Apoorv Mittal
> >
> >
> > On Wed, Nov 6, 2024 at 10:55 AM Lucas Brutschy
Hey Bill,
Thanks for the KIP! That all makes sense to me, just one minor note: while
you mentioned the TRACE recording level in the Motivation section, it seems
to be missing from the table in the Public Interfaces section. I assume
this will also be included, presumably with a value of 2?
Cheers
rceptor` object back. The
> > >> fundamental problem is, that we cannot know if the object we get is an
> > >> actually wrapper/intercpetor for the passed-in client, or if the
> object
> > >> is not wrapper at all, but a `new MyKafkaConsumer extends
>
A. Sophie Blee-Goldman created KAFKA-17805:
--
Summary: Deprecate named topologies
Key: KAFKA-17805
URL: https://issues.apache.org/jira/browse/KAFKA-17805
Project: Kafka
Issue Type
+1 (binding)
Thanks for this KIP!
On Mon, Oct 7, 2024 at 9:22 AM Kirk True wrote:
> Hi TengYao,
>
> +1 (non-binding)
>
> Thanks for all the work so far on this.
>
> Kirk
>
> On Mon, Oct 7, 2024, at 4:09 AM, TengYao Chi wrote:
> > Hi Andrew,
> >
> > Thanks for reviewing and participating in the
If this KIP is
> > going to immediately deprecate the old KafkaClientSupplier, then we need
> to
> > support implementing an interceptor while configured to use the current
> > rebalancing protocol.
>
> I don't think we need to do this, but we could make it mutu
gt; andrew_schofield_j...@outlook.com> wrote:
>
> > @sophie I meant AK tests. But you make a fair point. There will not be
> > that many instances I'm sure, so if the consensus is to deprecate the
> > old constructor, that's fine with me.
> >
> >
efault
> > >>>>> value, and this default should align with the existing
> > >> `Consumer#close()`
> > >>>>> method, which internally calls the overloaded
> > >> `Consumer#close(Duration)`
> > >>>>> with a default
September 2024 09:09
> > To: dev@kafka.apache.org
> > Subject: Re: [DISCUSS] KIP-1094 Add a new constructor method with
> nextOffsets to ConsumerRecords
> >
> > Thank you, Bill and Sophie.
> >
> > @Bill: You are right. I updated the KIP.
> > @Sophie
s not necessary for the plain consumer case.
> > >> >
> > >> > However, for the KS case it's different. Because KS uses the
> internal
> > >> > config to disable sending leave group request for dynamic members,
> we
> > >> > lack a
Thanks for the KIP! Quick request for readability, can you please include
the exact APIs that you're proposing to add or change under the "Public
Interfaces" section? The KIP should display the actual method signature and
any applicable javadocs for new public APIs.
You can look at other KIPs for
Should we deprecate the old constructor to make sure that all info gets
passed in when creating a ConsumerRecords instance?
On Thu, Sep 26, 2024 at 3:37 PM Bill Bejeck wrote:
> Hi Alieh,
>
> Thanks for the KIP, it will be very useful to Kafka Streams.
> I have one comment. In the "Proposed Chan
+1 (binding)
thanks for the KIP guys!
On Mon, Sep 23, 2024 at 3:38 AM Sebastien Viale <
sebastien.vi...@michelin.com> wrote:
> Hi everyone,
>
> Just a quick reminder that the vote for KIP-1034 is still open.
> Thank you all for your participation!
>
> Best regards,
> Damien Sebastien and Loic
>
all this, and still make a lot of deep
> changes to Kafka Streams (as mechanisms like probing rebalances etc.
> don't make sense in KIP-848). I think adapting KIP-848 to work with
> Kafka Streams either way is a big effort. Piggybacking on consumer
> group RPCs and extending the consume
our
> example
> > here <https://lists.apache.org/thread/l6dhq1rfl3xkq8g9wfqsvw89yjrgzbn8>
> > confused me since it contracts with the above sentence.
> >
> > Thanks,
> > Alieh
> >
> > On Fri, Sep 6, 2024 at 5:08 AM Sophie Blee-Goldman <
> sop...@res
/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol#KIP848:TheNextGenerationoftheConsumerRebalanceProtocol-AssignmentEpoch-Computethegroupassignment
> >
> > Its definition does not change at all, so we didn't describe it in
> > detail in KIP-1071.
> >
> &g
Kafka Streams, but this is
> true right now, too, so I don't think anything really changes.
>
> I guess, in the end, the new interface allows you to do everything you
> did before, but we still change the API contract a little bit, as Kafka
> Streams provides a client insta
Ah, my bad -- I thought I refreshed the page to get the latest version
which is why I was a bit confused when I couldn't find anything about the
new tools which I had previously seen in the KIP. Sorry for the confusion
and unnecessary questions
S1.
> You could imagine calling the initialize RPC
>
Also :
+1 (binding)
On Wed, Aug 28, 2024 at 3:48 PM Sophie Blee-Goldman
wrote:
> Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441 to
> consider a followup KIP for adding RETRY to the other exception handlers. I
> agree we can move on and vote this through
>
&
Congrats Lianet! Well deserved
On Wed, Aug 28, 2024 at 2:27 PM Jiashen Zhang
wrote:
> Congratulations Lianet! Awesome!
>
> On Wed, Aug 28, 2024 at 2:10 PM Andrew Schofield <
> andrew_schofi...@live.com>
> wrote:
>
> > Awesome news. Well done, Lianet.
> >
> > Andrew
> >
> > > On 28 Aug 2024, at 1
Thanks guys. I filed https://issues.apache.org/jira/browse/KAFKA-17441 to
consider a followup KIP for adding RETRY to the other exception handlers. I
agree we can move on and vote this through
On Thu, Aug 22, 2024 at 11:28 AM Matthias J. Sax wrote:
> Hi,
>
> given that there was no further feedb
A. Sophie Blee-Goldman created KAFKA-17441:
--
Summary: Add RETRY option to other exception handlers
Key: KAFKA-17441
URL: https://issues.apache.org/jira/browse/KAFKA-17441
Project: Kafka
Hey guys -- sorry I'm late to the party, I'm still going over some things
and don't have everything I want to say ready just yet, but I figured that
shouldn't stop me from starting with the questions/comments that are ready
to go. So here's my first set of feedback:
S1. Can you clarify which clien
t; deprecated, it seems we should deprecate all of them, too?
>
>
>
> -Matthias
>
>
> On 7/12/24 1:06 AM, Lucas Brutschy wrote:
> > Sounds good to me!
> >
> > +1 (binding)
> >
> > On Fri, Jul 12, 2024 at 12:55 AM Bill Bejeck wrote:
> >
Makes sense to me, +1 (binding)
On Thu, Jul 11, 2024 at 9:24 AM Matthias J. Sax wrote:
> Hi,
>
> I want to propose a very small KIP. Skipping the DISCUSS step, and
> calling for a VOTE directly.
>
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1070%3A+deprecate+MockProcessorContext
>
Thanks for the KIP -- definitely agree with this proposal, just have a few
suggestions:
1. In the KIP, you mention
We might also consider to not calling the handler when writing into
> internal topics, as those must exist.
Personally I would vote to consider all topics the same in this regard,
After reaching an agreement on the discussion thread, I'm giving this a +1
(binding) under the condition that we ship this change in 4.0 so as to
minimize the impact on users.
Thanks for the KIP!
-Sophie
On Thu, Jun 27, 2024 at 2:43 PM Sophie Blee-Goldman
wrote:
> I'll just not
I guess
> users need to change a couple of things in their code when they switch
> to 4.0, so those deprecations will carry (almost) no weight.
>
> What do you think?
>
> Best,
> Bruno
>
>
> On 6/15/24 8:58 AM, Sophie Blee-Goldman wrote:
> > I think we should pause
I'll just note that I will personally be abstaining from this vote, but
won't vote -1 and just want to defer to the rest of the community on this.
I've stated my concerns in the discussion thread and will leave it at that
-- if we hear from users who actively support this change and want it to
happ
+1 (binding) thanks Nick!
On Thu, Jun 13, 2024 at 12:39 AM Bruno Cadonna wrote:
> Thanks Nick!
>
> Great KIP!
>
> +1 (binding)
>
> Best,
> Bruno
>
> On 6/13/24 2:31 AM, Matthias J. Sax wrote:
> > Thanks Nick.
> >
> > +1 (binding)
> >
> >
> > Looking forward to get this all merged!
> >
> >
> > -M
I think we should pause for a minute and have an honest conversation about
whether the benefits of making this change outweigh the negatives. Here's
my quick roundup of the positives and negatives, feel free to add to this
list if there's else you think should be considered but then let's evaluate
1 - 100 of 911 matches
Mail list logo
