This is super useful for pipeline setup!
+1 (non binding)
On Mon, Oct 9, 2023, 7:57 AM Chris Egerton wrote:
> Thanks for the KIP, Yash!
>
> +1 (binding)
>
> On Mon, Oct 9, 2023, 01:12 Yash Mayya wrote:
>
> > Hi all,
> >
> > I'd like to start a vote on KIP-980 which proposes allowing the creati
+1 (non binding)
On Mon, Apr 8, 2024, 3:30 PM Chris Egerton wrote:
> Thanks Ivan! +1 (binding) from me.
>
> On Mon, Apr 8, 2024, 06:59 Ivan Yurchenko wrote:
>
> > Hello!
> >
> > I'd like to put the subj KIP[1] to a vote. Thank you.
> >
> > Best regards,
> > Ivan
> >
> > [1]
> >
> https://cwiki.
Alieh,
Having run into issues with not being able to handle producer failures, I
think this is good functionality to have.
With this new functionality proposed at the Producer level, how would
ecosystems that sit on top of it function? Specifically, Connect was
updated a few years ago to allow So
This would be helpful. For our own client library wrappers we implemented
this functionality for any type with defaults for and
consumers/producers.
On Thu, Nov 10, 2022, 6:35 PM Dan S wrote:
> Hello all,
>
> I think that adding builders for the producer and the consumer in kafka
> client woul
+1 (non binding)
On Tue, Jan 24, 2023 at 5:24 AM Yash Mayya wrote:
> Hi Chris,
>
> I'm +1 (non-binding). Thanks again for proposing this extremely
> valuable addition to Kafka Connect!
>
> Thanks,
> Yash
>
> On Thu, Jan 19, 2023 at 12:11 AM Chris Egerton
> wrote:
>
> > Hi all,
> >
> > I'd like
+1 (non binding)
On Mon, Feb 27, 2023 at 11:21 AM Chris Egerton
wrote:
> Hi all,
>
> I could have sworn I +1'd this but I can't seem to find a record of that.
>
> In the hopes that this action is idempotent, +1 (binding). Thanks for the
> KIP!
>
> Cheers,
>
> Chris
>
> On Mon, Feb 27, 2023 at 6:
Good afternoon all,
In our Kafka clusters we have a need to know when certain activities are
performed, mainly topics being created, but brokers coming up/down is also
useful. This would be akin to what ActiveMQ does via advisory messages (
https://activemq.apache.org/advisory-message).
Since the
eful, but a good news is that in KIP-500
> > > <
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum
> > > >
> > > we
> > > are trying to deprecate Zookeeper and migrate t
Requesting Jira contributor access.
Username: katchison
Good morning,
I would like to author a KIP.
May I please have permissions granted for the wiki?
username: katchison
Thank you.
Knowles
Done. Thanks for your interest in Apache Kafka.
>
> -Bill
>
> On Tue, Oct 5, 2021 at 10:54 AM Knowles Atchison Jr >
> wrote:
>
> > Good morning,
> >
> > I would like to author a KIP.
> >
> > May I please have permissions granted for the wiki?
> >
> > username: katchison
> >
> > Thank you.
> >
> > Knowles
> >
>
Hello all,
I would like to discuss the following KIP:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-779%3A+Allow+Source+Tasks+to+Handle+Producer+Exceptions
The main purpose is to allow Source Tasks the ability to see underlying
Producer Exceptions and decide what to do rather than being
Good morning,
Bumping this for visibility. I would like this to go into the next release.
KIP freeze is Friday.
Any comments and feedback are welcome.
Knowles
On Tue, Oct 5, 2021 at 4:24 PM Knowles Atchison Jr
wrote:
> Hello all,
>
> I would like to discuss the following KIP:
&g
Good morning,
The current process of KIPs needs to be improved. There are at least a
handful of open KIPs with existing PRs that are in a purgatory state. I
understand that people are busy, but if you are going to gatekeep Kafka
with this process, then it must be responsive. Even if the community
Christopher Shannon <
christopher.l.shan...@gmail.com> wrote:
> I also would find this feature useful to handle errors better, does anyone
> have any comments or feedback?
>
>
> On Mon, Oct 11, 2021 at 8:52 AM Knowles Atchison Jr >
> wrote:
>
> > Good morning,
to send, since
> there's a non-trivial transformation that takes place to
> convert the SourceRecord into a ProducerRecord. I'm not sure
> what people would do with it, exactly, but it might be
> helpful in deciding what to do about the exception, or maybe
> even in understan
I wonder if it's safe to allow connectors to discard this
> > exception when they're running with exactly-once support, or if the task
> > should still be unconditionally failed in that case?
> >
> > Cheers,
> >
> > Chris
> >
> > On Wed, Oc
Record() on it?
>
> On Thu, Oct 28, 2021 at 9:35 AM Knowles Atchison Jr >
> wrote:
>
> > Hi Chris,
> >
> > Thank you for your reply!
> >
> > It is a clarity error regarding the javadoc. I am not operationally
> > familiar with all of the except
at 10:39 AM Knowles Atchison Jr <
> katchiso...@gmail.com>
> wrote:
>
> > That would work. I originally thought that it would be confusing to
> > overload that function when a Record that wasn't actually written, but
> > looking at SourceTask more closely, in c
k. Effectively, if error.tolerance is set to all, then the
> behavior would be like how you describe the worker would ignore producer
> errors.
>
> 2. If we do choose to have a new config, could you please call out the
> possible values it can take in the kip?
>
> Thanks again!
Good morning,
If there is no additional feedback, I am going to call a vote for this KIP
on Monday.
Knowles
On Tue, Nov 2, 2021 at 10:00 AM Knowles Atchison Jr
wrote:
> Third time's the charm.
>
> I've added a getter for the RetryWithToleranceOperator to get the
> Toler
Good morning,
I'd like to start a vote for KIP-779: Allow Source Tasks to Handle Producer
Exceptions:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-779%3A+Allow+Source+Tasks+to+Handle+Producer+Exceptions
The purpose of this KIP is to allow Source Tasks the option to "ignore"
kafka produc
that they came from seems
> like a reasonable alternative. I think we're probably past the point of
> making that happen in this KIP, but I don't believe the changes you've
> proposed make that any harder in the future than it is now (which is
> great!), and I wanted to voic
es. It's a bit crummy when
> > upgrading, but I do think it's better than introducing a new
> configuration
> > in the long term.
> >
> > On Mon, Nov 15, 2021 at 2:52 PM Knowles Atchison Jr <
> katchiso...@gmail.com>
> > wrote:
> >
> >&g
t; > > 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
Good morning,
Bringing this back to the top.
We currently have
1 binding
4 non-binding
Knowles
On Fri, Nov 19, 2021 at 10:02 AM Knowles Atchison Jr
wrote:
> Thank you all for voting. We still need two more binding votes.
>
> I have rebased and updated the PR to be ready to go once
Bentley wrote:
> Hi Knowles,
>
> Thanks for the KIP, +1 (binding)
>
> Kind regards,
>
> Tom
>
> On 11/29/21, Mickael Maison wrote:
> > Hi Knowles,
> >
> > +1 (binding)
> >
> > Thanks for the KIP!
> >
> > On Mon, Nov 29, 20
Good morning,
Any additional feedback and/or review on the PR for this change would be
greatly appreciated:
https://github.com/apache/kafka/pull/11382
Knowles
On Tue, Nov 16, 2021 at 4:02 PM Knowles Atchison Jr
wrote:
> Thank you all for the feedback, the KIP has been updated.
>
&g
Knowles Atchison Jr created KAFKA-13348:
---
Summary: Allow Source Tasks to Handle Producer Exceptions
Key: KAFKA-13348
URL: https://issues.apache.org/jira/browse/KAFKA-13348
Project: Kafka
29 matches
Mail list logo
