Hi Shekhar,

Thanks for the KIP.

I was wondering if you could also add a section on how message ordering can
no longer be guaranteed at partition level ? Some connectors (eg: JDBC
sink) rely on ordering of messages in a topic partition to set the values
correctly in the sink system. How do we protect users from turning this
feature on for a connector which requires ordering ?

 If we want to support changing the consumer group type for a running
connector, we may have to change the default group name as it may clash
with the previous group.

Thanks,
Ashwin

On Tue, Mar 31, 2026 at 6:37 AM Chris Egerton <[email protected]>
wrote:

> Hi,
>
> Does this cover sink connectors whose tasks process records asynchronously
> (i.e., ones that return from SinkTask::put before all records received in
> that call have been written to the external system, and override
> SinkTask::preCommit to control exactly which offsets are safe to commit to
> Kafka)? I understand that the KIP aims to move incrementally (for example,
> by only supporting at-least-once delivery semantics), but IMO support for
> these kinds of connectors is a must-have for any KIP that adds support for
> share groups to Kafka Connect sink connectors.
>
> Cheers,
>
> Chris
>
> On Mon, Mar 30, 2026 at 1:35 PM Shekhar Prasad Rajak via dev <
> [email protected]> wrote:
>
> > KIP link :
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1302%3A+Support+Share+Groups+%28Queue+Semantics%29+in+Kafka+Connect+Sink+Connectors
> >
> >
> >
> > Best,Shekhar
> >
> >
> >
> >
> >     On Monday 30 March 2026 at 02:38:23 pm GMT+5:30, Shekhar Prasad Rajak
> > via dev <[email protected]> wrote:
> >
> >   Hi Team,
> > I’m opening this thread for us to collaboratively finalize our strategy
> > for integrating Share Groups (Queue Semantics) into Kafka Connect Sink
> > Connectors, as outlined in KIP-1301.
> > By leveraging the foundational work from KIP-1289 and KIP-1191 we have a
> > unique opportunity to implement architectural improvements. This approach
> > will significantly boost throughput and performance while streamlining
> our
> > workflows to ensure minimal long-term maintenance.
> > I propose a phased execution, starting with a lean MVP to get us moving
> > quickly.
> >
> > Links:
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1289+Support+Transactional+Acknowledgments+for+Share+Groups
> >
> >
> >
> > Best,
> > Shekhar
> >
> >
> >
>

Reply via email to