Re: [ANNOUNCE] New committer: Divij Vaidya

[Divij Vaidya]

Thank you everyone! I promise to shoulder this new responsibility to the
best of my abilities.

--
Divij Vaidya



On Wed, Jun 14, 2023 at 4:13 AM ziming deng 
wrote:

> Congratulations, Divij!
> Well deserved!
>
> --
> Ziming
>
> > On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> >
> > Congratulations, Divij!
> > Well deserved!
> >
> > Luke
> >
> > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> >  wrote:
> >
> >> Congrats Divij!
> >>
> >> On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:
> >>
> >>> Congrats!
> >>>
> >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch 
> wrote:
> >>>
>  Congratulations!
> 
>  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
> >>> wrote:
> 
> > Congrats!
> >
> > On 6/13/23 10:24 AM, Satish Duggana wrote:
> >> Congratulations Divij!!
> >>
> >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> >>  wrote:
> >>>
> >>> Congratulations Divij.
> >>>
> >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
>  wrote:
> >>>
>  Hi all,
> 
>  The PMC of Apache Kafka is pleased to announce a new Kafka
> >>> committer
>  Divij Vaidya.
> 
>  Divij's major contributions are:
> 
>  GDPR compliance enforcement of kafka-site -
>  https://issues.apache.org/jira/browse/KAFKA-13868
> 
>  Performance improvements:
> 
>  Improve performance of VarInt encoding and decoding -
>  https://github.com/apache/kafka/pull/13312
> 
>  Reduce data copy & buffer allocation during decompression -
>  https://github.com/apache/kafka/pull/13135
> 
>  He also was heavily involved in the migration to Mockito.
> 
>  Furthermore, Divij is very active on the mailing lists as well as
> >>> in
>  maintaining and reviewing pull requests.
> 
>  Congratulations, Divij!
> 
>  Thanks,
> 
>  Bruno (on behalf of the Apache Kafka PMC)
> 
> 
>  --
> >>> Manyanda Chitimbo.
> >
> 
> >>>
> >>
>
>

Re: [ANNOUNCE] New committer: Divij Vaidya

[Federico Valeri]

Congrats Divij!

On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya  wrote:
>
> Thank you everyone! I promise to shoulder this new responsibility to the
> best of my abilities.
>
> --
> Divij Vaidya
>
>
>
> On Wed, Jun 14, 2023 at 4:13 AM ziming deng 
> wrote:
>
> > Congratulations, Divij!
> > Well deserved!
> >
> > --
> > Ziming
> >
> > > On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> > >
> > > Congratulations, Divij!
> > > Well deserved!
> > >
> > > Luke
> > >
> > > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> > >  wrote:
> > >
> > >> Congrats Divij!
> > >>
> > >> On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:
> > >>
> > >>> Congrats!
> > >>>
> > >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch 
> > wrote:
> > >>>
> >  Congratulations!
> > 
> >  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
> > >>> wrote:
> > 
> > > Congrats!
> > >
> > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > >> Congratulations Divij!!
> > >>
> > >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > >>  wrote:
> > >>>
> > >>> Congratulations Divij.
> > >>>
> > >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
> >  wrote:
> > >>>
> >  Hi all,
> > 
> >  The PMC of Apache Kafka is pleased to announce a new Kafka
> > >>> committer
> >  Divij Vaidya.
> > 
> >  Divij's major contributions are:
> > 
> >  GDPR compliance enforcement of kafka-site -
> >  https://issues.apache.org/jira/browse/KAFKA-13868
> > 
> >  Performance improvements:
> > 
> >  Improve performance of VarInt encoding and decoding -
> >  https://github.com/apache/kafka/pull/13312
> > 
> >  Reduce data copy & buffer allocation during decompression -
> >  https://github.com/apache/kafka/pull/13135
> > 
> >  He also was heavily involved in the migration to Mockito.
> > 
> >  Furthermore, Divij is very active on the mailing lists as well as
> > >>> in
> >  maintaining and reviewing pull requests.
> > 
> >  Congratulations, Divij!
> > 
> >  Thanks,
> > 
> >  Bruno (on behalf of the Apache Kafka PMC)
> > 
> > 
> >  --
> > >>> Manyanda Chitimbo.
> > >
> > 
> > >>>
> > >>
> >
> >

[jira] [Created] (KAFKA-15085) Make Timer.java implement AutoCloseable

[Divij Vaidya (Jira)]

Divij Vaidya created KAFKA-15085:


 Summary: Make Timer.java implement AutoCloseable
 Key: KAFKA-15085
 URL: https://issues.apache.org/jira/browse/KAFKA-15085
 Project: Kafka
  Issue Type: Improvement
  Components: core
Reporter: Divij Vaidya


Many automatic bug finders will flag a warning if an object of class which is 
marked as AutoCloseable but is not closed properly in the code. Hence, as a 
best practice we should implement AutoCloseable for classes which require 
resources to be released after shutdown.

Timer.java should implement AutoCloseable and ShutDown should be replaced with 
close() method.

Note that this interface change does not require a KIP since Timer.java is not 
a user facing public class.

This was discussed here: 
[https://github.com/apache/kafka/pull/13820#discussion_r1222654614] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [kafka-site] divijvaidya commented on a diff in pull request #516: MINOR: Add blog for 3.5.0 release

[via GitHub]

divijvaidya commented on code in PR #516:
URL: https://github.com/apache/kafka-site/pull/516#discussion_r1229310063


##
blog.html:
##
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+Blog

Review Comment:
   @mimaison thoughts about this?



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] mimaison commented on a diff in pull request #516: MINOR: Add blog for 3.5.0 release

[via GitHub]

mimaison commented on code in PR #516:
URL: https://github.com/apache/kafka-site/pull/516#discussion_r1229313276


##
blog.html:
##
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+Blog

Review Comment:
   No plans currently but if anybody is interested in posting non-release 
content, why not!



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] divijvaidya commented on a diff in pull request #516: MINOR: Add blog for 3.5.0 release

[via GitHub]

divijvaidya commented on code in PR #516:
URL: https://github.com/apache/kafka-site/pull/516#discussion_r1229318237


##
blog.html:
##
@@ -0,0 +1,70 @@
+
+
+
+
+
+
+
+
+Blog

Review Comment:
   ok, in that case let's keep it as a blog. 



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[GitHub] [kafka-site] divijvaidya commented on a diff in pull request #516: MINOR: Add blog for 3.5.0 release

[via GitHub]

divijvaidya commented on code in PR #516:
URL: https://github.com/apache/kafka-site/pull/516#discussion_r1229322282


##
blog.html:
##
@@ -0,0 +1,71 @@
+
+
+
+
+
+
+
+
+Blog
+
+
+
+Apache 
Kafka 3.5.0 Release Announcement
+
+15 June 2023 - Mickael Maison (https://twitter.com/MickaelMaison";>@MickaelMaison)
+We are proud to announce the release of Apache Kafka 3.5.0. 
This release contains many new features and improvements. This blog post will 
highlight some of the more prominent features. For a full list of changes, be 
sure to check the https://downloads.apache.org/kafka/3.5.0/RELEASE_NOTES.html";>release 
notes.
+See the https://kafka.apache.org/35/documentation.html#upgrade_3_5_0";>Upgrading 
to 3.5.0 from any version 0.8.x through 3.4.x section in the documentation 
for the list of notable changes and detailed upgrade steps.
+The ability to migrate Kafka clusters from ZK to KRaft mode 
with no downtime is still an early access feature. It is currently only 
suitable for testing in non production environments. See https://cwiki.apache.org/confluence/display/KAFKA/KIP-866+ZooKeeper+to+KRaft+Migration";>KIP-866
 for more details.
+Kafka Broker, Controller, Producer, Consumer and Admin 
Client
+
+KIP-881: Rack-aware Partition Assignment for Kafka 
Consumers: Kafka 3.4.0 only contained the protocol changes for https://cwiki.apache.org/confluence/display/KAFKA/KIP-881%3A+Rack-aware+Partition+Assignment+for+Kafka+Consumers";>KIP-881.
 The built-in assignors have now been updated to support rack-awareness.
+KIP-887: Add ConfigProvider to make use of environment 
variables: https://cwiki.apache.org/confluence/display/KAFKA/KIP-887%3A+Add+ConfigProvider+to+make+use+of+environment+variables";>KIP-887
 introduces a new https://kafka.apache.org/35/javadoc/org/apache/kafka/common/config/provider/ConfigProvider.html";>ConfigProvider
 implementation, EnvVarConfigProvider, to retrieve configurations 
from environment variables.
+KIP-900: KRaft kafka-storage.sh API additions to 
support SCRAM for Kafka Brokers: https://cwiki.apache.org/confluence/display/KAFKA/KIP-900%3A+KRaft+kafka-storage.sh+API+additions+to+support+SCRAM+for+Kafka+Brokers";>KIP-900
 updates the kafka-storage tool and adds a mechanism to configure 
SCRAM for inter broker authentication with KRaft.
+KIP-903: Replicas with stale broker epoch should not be 
allowed to join the ISR: https://cwiki.apache.org/confluence/display/KAFKA/KIP-903%3A+Replicas+with+stale+broker+epoch+should+not+be+allowed+to+join+the+ISR";>KIP-903
 addresses a limitation of the inter broker replication protocol which could 
lead to data loss in case of a broker failing while another broker had an 
unclean shutdown.
+
+Kafka Streams
+
+KIP-399: Extend ProductionExceptionHandler to cover 
serialization exceptions: https://cwiki.apache.org/confluence/display/KAFKA/KIP-399%3A+Extend+ProductionExceptionHandler+to+cover+serialization+exceptions";>KIP-399
 adds a method, handleSerializationException(), to the 
ProductionExceptionHandler interface to handle any serialization 
errors encountered while producing records.
+KIP-889: Versioned State Stores: https://cwiki.apache.org/confluence/display/KAFKA/KIP-889%3A+Versioned+State+Stores";>KIP-889
 introduces versioned state stores to improve the accuracy of joins when out of 
order records are processed.
+KIP-907: Add Boolean Serde to public interface: 
Kafka Streams includes built-in Serdes for most primitive types. https://cwiki.apache.org/confluence/display/KAFKA/KIP-907%3A+Add+Boolean+Serde+to+public+interface";>KIP-907
 adds a new one for booleans.
+
+Kafka Connect
+
+KIP-710: Full support for distributed mode in dedicated 
MirrorMaker 2.0 clusters: https://cwiki.apache.org/confluence/display/KAFKA/KIP-710%3A+Full+support+for+distributed+mode+in+dedicated+MirrorMaker+2.0+clusters";>KIP-710
 improves the dedicated mode of MirrorMaker. It now supports running multiple 
instances and handling automatic reconfigurations.
+KIP-875: First-class offsets support in Kafka 
Connect: https://cwiki.apache.org/confluence/display/KAFKA/KIP-875%3A+First-class+offsets+support+in+Kafka+Connect";>KIP-875
 adds REST API endpoints for managing offset of Connectors. 3.5.0 only contains 
endpoints for listing offsets. Endpoints for updating and deleting offsets will 
come in a future release.
+KIP-894: Use incrementalAlterConfig for syncing topic 
configurations: With https://cwiki.apache.org/confluence/display/KAFKA/KIP-894%3A+Use+incrementalAlterConfigs+API+for+syncing+top

Re: [ANNOUNCE] New committer: Divij Vaidya

[Lucas Brutschy]

Congrats!!

On Wed, Jun 14, 2023 at 11:02 AM Federico Valeri  wrote:
>
> Congrats Divij!
>
> On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya  wrote:
> >
> > Thank you everyone! I promise to shoulder this new responsibility to the
> > best of my abilities.
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Wed, Jun 14, 2023 at 4:13 AM ziming deng 
> > wrote:
> >
> > > Congratulations, Divij!
> > > Well deserved!
> > >
> > > --
> > > Ziming
> > >
> > > > On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> > > >
> > > > Congratulations, Divij!
> > > > Well deserved!
> > > >
> > > > Luke
> > > >
> > > > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> > > >  wrote:
> > > >
> > > >> Congrats Divij!
> > > >>
> > > >> On Tue, Jun 13, 2023, 20:27 Philip Nee  wrote:
> > > >>
> > > >>> Congrats!
> > > >>>
> > > >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch 
> > > wrote:
> > > >>>
> > >  Congratulations!
> > > 
> > >  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax 
> > > >>> wrote:
> > > 
> > > > Congrats!
> > > >
> > > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > >> Congratulations Divij!!
> > > >>
> > > >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > >>  wrote:
> > > >>>
> > > >>> Congratulations Divij.
> > > >>>
> > > >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna 
> > >  wrote:
> > > >>>
> > >  Hi all,
> > > 
> > >  The PMC of Apache Kafka is pleased to announce a new Kafka
> > > >>> committer
> > >  Divij Vaidya.
> > > 
> > >  Divij's major contributions are:
> > > 
> > >  GDPR compliance enforcement of kafka-site -
> > >  https://issues.apache.org/jira/browse/KAFKA-13868
> > > 
> > >  Performance improvements:
> > > 
> > >  Improve performance of VarInt encoding and decoding -
> > >  https://github.com/apache/kafka/pull/13312
> > > 
> > >  Reduce data copy & buffer allocation during decompression -
> > >  https://github.com/apache/kafka/pull/13135
> > > 
> > >  He also was heavily involved in the migration to Mockito.
> > > 
> > >  Furthermore, Divij is very active on the mailing lists as well as
> > > >>> in
> > >  maintaining and reviewing pull requests.
> > > 
> > >  Congratulations, Divij!
> > > 
> > >  Thanks,
> > > 
> > >  Bruno (on behalf of the Apache Kafka PMC)
> > > 
> > > 
> > >  --
> > > >>> Manyanda Chitimbo.
> > > >
> > > 
> > > >>>
> > > >>
> > >
> > >

Re: [ANNOUNCE] New committer: Divij Vaidya

[Josep Prat]

Congrats Divij!

On Wed, Jun 14, 2023 at 11:45 AM Lucas Brutschy
 wrote:

> Congrats!!
>
> On Wed, Jun 14, 2023 at 11:02 AM Federico Valeri 
> wrote:
> >
> > Congrats Divij!
> >
> > On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya 
> wrote:
> > >
> > > Thank you everyone! I promise to shoulder this new responsibility to
> the
> > > best of my abilities.
> > >
> > > --
> > > Divij Vaidya
> > >
> > >
> > >
> > > On Wed, Jun 14, 2023 at 4:13 AM ziming deng 
> > > wrote:
> > >
> > > > Congratulations, Divij!
> > > > Well deserved!
> > > >
> > > > --
> > > > Ziming
> > > >
> > > > > On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> > > > >
> > > > > Congratulations, Divij!
> > > > > Well deserved!
> > > > >
> > > > > Luke
> > > > >
> > > > > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> > > > >  wrote:
> > > > >
> > > > >> Congrats Divij!
> > > > >>
> > > > >> On Tue, Jun 13, 2023, 20:27 Philip Nee 
> wrote:
> > > > >>
> > > > >>> Congrats!
> > > > >>>
> > > > >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch 
> > > > wrote:
> > > > >>>
> > > >  Congratulations!
> > > > 
> > > >  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax <
> mj...@apache.org>
> > > > >>> wrote:
> > > > 
> > > > > Congrats!
> > > > >
> > > > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > > >> Congratulations Divij!!
> > > > >>
> > > > >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > > >>  wrote:
> > > > >>>
> > > > >>> Congratulations Divij.
> > > > >>>
> > > > >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna <
> cado...@apache.org>
> > > >  wrote:
> > > > >>>
> > > >  Hi all,
> > > > 
> > > >  The PMC of Apache Kafka is pleased to announce a new Kafka
> > > > >>> committer
> > > >  Divij Vaidya.
> > > > 
> > > >  Divij's major contributions are:
> > > > 
> > > >  GDPR compliance enforcement of kafka-site -
> > > >  https://issues.apache.org/jira/browse/KAFKA-13868
> > > > 
> > > >  Performance improvements:
> > > > 
> > > >  Improve performance of VarInt encoding and decoding -
> > > >  https://github.com/apache/kafka/pull/13312
> > > > 
> > > >  Reduce data copy & buffer allocation during decompression -
> > > >  https://github.com/apache/kafka/pull/13135
> > > > 
> > > >  He also was heavily involved in the migration to Mockito.
> > > > 
> > > >  Furthermore, Divij is very active on the mailing lists as
> well as
> > > > >>> in
> > > >  maintaining and reviewing pull requests.
> > > > 
> > > >  Congratulations, Divij!
> > > > 
> > > >  Thanks,
> > > > 
> > > >  Bruno (on behalf of the Apache Kafka PMC)
> > > > 
> > > > 
> > > >  --
> > > > >>> Manyanda Chitimbo.
> > > > >
> > > > 
> > > > >>>
> > > > >>
> > > >
> > > >
>


-- 
[image: Aiven] 

*Josep Prat*
Open Source Engineering Director, *Aiven*
josep.p...@aiven.io   |   +491715557497
aiven.io    |   
     
*Aiven Deutschland GmbH*
Alexanderufer 3-7, 10117 Berlin
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
Amtsgericht Charlottenburg, HRB 209739 B

[jira] [Created] (KAFKA-15086) The unreasonable segment size setting of the internal topics in MM2 may cause the worker startup time to be too long

[hudeqi (Jira)]

hudeqi created KAFKA-15086:
--

 Summary: The unreasonable segment size setting of the internal 
topics in MM2 may cause the worker startup time to be too long
 Key: KAFKA-15086
 URL: https://issues.apache.org/jira/browse/KAFKA-15086
 Project: Kafka
  Issue Type: Improvement
  Components: mirrormaker
Affects Versions: 3.4.1
Reporter: hudeqi
Assignee: hudeqi


As the config 'segment.bytes' for topics related MM2(such as 
offset.storage.topic, config.storage.topic,status.storage.topic), if following 
the default configuration of the broker or set it larger, then when the MM 
cluster runs many and complicated tasks, especially the log volume of the topic 
'offset.storage.topic' is very large, it will affect the restart speed of the 
MM workers.

After investigation, the reason is that a consumer needs to be started to read 
the data of ‘offset.storage.topic’ at startup. Although this topic is set to 
compact, if the 'segment size' is set to a large value, such as the default 
value of 1G, then this topic may have tens of gigabytes of data that cannot be 
compacted and has to be read from the earliest (because the active segment 
cannot be cleaned), which will consume a lot of time (in our online 
environment, we found that this topic stores 13G of data, it took nearly half 
an hour for all the data to be consumed), which caused the worker to be unable 
to start and execute tasks for a long time.
Of course, the number of consumer threads can also be adjusted, but I think it 
may be easier to reduce the 'segment size', for example, refer to the default 
value of __consumer_offsets: 100MB



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [kafka-site] divijvaidya closed pull request #477: Add recommendation in coding style guide about usage of Option.exists

[via GitHub]

divijvaidya closed pull request #477: Add recommendation in coding style guide 
about usage of Option.exists
URL: https://github.com/apache/kafka-site/pull/477


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (KAFKA-15087) Move InterBrokerSendThread to server-commons module

[Dimitar Dimitrov (Jira)]

Dimitar Dimitrov created KAFKA-15087:


 Summary: Move InterBrokerSendThread to server-commons module
 Key: KAFKA-15087
 URL: https://issues.apache.org/jira/browse/KAFKA-15087
 Project: Kafka
  Issue Type: Task
Reporter: Dimitar Dimitrov
Assignee: Dimitar Dimitrov


Similar to the move of {{ShutdownableThread}} done with KAFKA-14706.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[GitHub] [kafka-site] divijvaidya opened a new pull request, #523: Add Divij Vaidya to committers page

[via GitHub]

divijvaidya opened a new pull request, #523:
URL: https://github.com/apache/kafka-site/pull/523

   ## Change
   Add bio to the committers page
   
   ## Testing
   Tested the change by running website locally. See below image for result.
   
   ![Screenshot 2023-06-14 at 13 13 
41](https://github.com/apache/kafka-site/assets/71267/db0393d5-f51a-47a1-9f12-89e53e43fcc9)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Re: [DISCUSS] KIP-910: Update Source offsets for Source Connectors without producing records

[Sagar]

Hey All,

Bumping this discussion thread again to see how the modified KIP looks
like.

Thanks!
Sagar.

On Mon, May 29, 2023 at 8:12 PM Sagar  wrote:

> Hi,
>
> Bumping this thread again for further reviews.
>
> Thanks!
> Sagar.
>
> On Fri, May 12, 2023 at 3:38 PM Sagar  wrote:
>
>> Hi All,
>>
>> Thanks for the comments/reviews. I have updated the KIP
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-910%3A+Update+Source+offsets+for+Source+Connectors+without+producing+records
>> with a newer approach which shelves the need for an explicit topic.
>>
>> Please review again and let me know what you think.
>>
>> Thanks!
>> Sagar.
>>
>>
>> On Mon, Apr 24, 2023 at 3:35 PM Yash Mayya  wrote:
>>
>>> Hi Sagar,
>>>
>>> Thanks for the KIP! I have a few questions and comments:
>>>
>>> 1) I agree with Chris' point about the separation of a connector
>>> heartbeat
>>> mechanism and allowing source connectors to generate offsets without
>>> producing data. What is the purpose of the heartbeat topic here and are
>>> there any concrete use cases for downstream consumers on this topic? Why
>>> can't we instead simply introduce a mechanism to retrieve a list of
>>> source
>>> partition / source offset pairs from the source tasks?
>>>
>>> 2) With the currently described mechanism, the new
>>> "SourceTask::produceHeartbeatRecords" method returns a
>>> "List"
>>> - what happens with the topic in each of these source records? Chris
>>> pointed this out above, but it doesn't seem to have been addressed? The
>>> "SourceRecord" class also has a bunch of other fields which will be
>>> irrelevant here (partition, key / value schema, key / value data,
>>> timestamp, headers). In fact, it seems like only the source partition and
>>> source offset are relevant here, so we should either introduce a new
>>> abstraction or simply use a data structure like a mapping from source
>>> partitions to source offsets (adds to the above point)?
>>>
>>> 3) I'm not sure I fully follow why the heartbeat timer / interval is
>>> needed? What are the downsides of
>>> calling "SourceTask::produceHeartbeatRecords" in every execution loop
>>> (similar to the existing "SourceTask::poll" method)? Is this only to
>>> prevent the generation of a lot of offset records? Since Connect's
>>> offsets
>>> topics are log compacted (and source partitions are used as keys for each
>>> source offset), I'm not sure if such concerns are valid and such a
>>> heartbeat timer / interval mechanism is required?
>>>
>>> 4) The first couple of rejected alternatives state that the use of a null
>>> topic / key / value are preferably avoided - but the current proposal
>>> would
>>> also likely require connectors to use such workarounds (null topic when
>>> the
>>> heartbeat topic is configured at a worker level and always for the key /
>>> value)?
>>>
>>> 5) The third rejected alternative talks about subclassing the
>>> "SourceRecord" class - this presumably means allowing connectors to pass
>>> special offset only records via the existing poll mechanism? Why was this
>>> considered a more invasive option? Was it because of the backward
>>> compatibility issues that would be introduced for plugins using the new
>>> public API class that still need to be deployed onto older Connect
>>> workers?
>>>
>>> Thanks,
>>> Yash
>>>
>>> On Fri, Apr 14, 2023 at 6:45 PM Sagar  wrote:
>>>
>>> > One thing I forgot to mention in my previous email was that the reason
>>> I
>>> > chose to include the opt-in behaviour via configs was that the users
>>> of the
>>> > connector know their workload patterns. If the workload is such that
>>> the
>>> >  connector would receive regular valid updates then there’s ideally no
>>> need
>>> > for moving offsets since it would update automatically.
>>> >
>>> > This way they aren’t forced to use this feature and can use it only
>>> when
>>> > the workload is expected to be batchy or not frequent.
>>> >
>>> > Thanks!
>>> > Sagar.
>>> >
>>> >
>>> > On Fri, 14 Apr 2023 at 5:32 PM, Sagar 
>>> wrote:
>>> >
>>> > > Hi Chris,
>>> > >
>>> > > Thanks for following up on the response. Sharing my thoughts further:
>>> > >
>>> > > If we want to add support for connectors to emit offsets without
>>> > >> accompanying source records, we could (and IMO should) do that
>>> without
>>> > >> requiring users to manually enable that feature by adjusting worker
>>> or
>>> > >> connector configurations.
>>> > >
>>> > >
>>> > > With the current KIP design, I have tried to implement this in an
>>> opt-in
>>> > > manner via configs. I guess what you are trying to say is that this
>>> > doesn't
>>> > > need a config of it's own and instead could be part of the poll ->
>>> > > transform etc -> produce -> commit cycle. That way, the users don't
>>> need
>>> > to
>>> > > set any config and if the connector supports moving offsets w/o
>>> producing
>>> > > SourceRecords, it should happen automatically. Is that correct? If
>>> that
>>> > > is the concern, then I can think of not exposing

[jira] [Created] (KAFKA-15088) Fixing Incorrect Reference Usage in Connector State Changes

[Daeho Kim (Jira)]

Daeho Kim created KAFKA-15088:
-

 Summary: Fixing Incorrect Reference Usage in Connector State 
Changes
 Key: KAFKA-15088
 URL: https://issues.apache.org/jira/browse/KAFKA-15088
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Reporter: Daeho Kim


Currently, in the AbstractHerder class, the behavior of state changes for 
Connectors and Tasks is handled by implementing Listener using the 
ConnectorStatus and TaskStatus classes, which inherit from AbstractStatus. 
However, the code implementing the state change behavior in ConnectorStatus 
refers to and uses an inappropriate State enum class.

Both ConnectorStatus and TaskStatus inherit and implement AbstractStatus, and 
as a result, they share the State class. However, there is a need to make 
modifications for clear referencing. We need to fix the implementation in 
ConnectorStatus to use the appropriate reference for state changes.

This bug ticket will address the task of modifying the code to use the correct 
reference for Connector state changes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] KIP-864: Add End-To-End Latency Metrics to Connectors

[Matthew Benedict de Detrich]

Gets a +1 from me (non binding). Greatly helps debugging problematic
connectors.

On Thu, May 11, 2023 at 5:33 PM Hector Geraldino (BLOOMBERG/ 919 3RD A) <
hgerald...@bloomberg.net> wrote:

> This will help us greatly. +1 (non-binding)
>
> From: dev@kafka.apache.org At: 05/10/23 17:32:35 UTC-4:00To:
> dev@kafka.apache.org
> Subject: Re: [VOTE] KIP-864: Add End-To-End Latency Metrics to Connectors
>
> Hi everyone,
>
> Bumping this vote thread. 2 +1 binding and 1 +1 non-binding so far.
>
> Cheers,
> Jorge.
>
> On Mon, 27 Feb 2023 at 18:56, Knowles Atchison Jr 
> wrote:
>
> > +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:28 AM Mickael Maison <
> mickael.mai...@gmail.com
> > >
> > > wrote:
> > >
> > > > Thanks for the KIP
> > > >
> > > > +1 (binding)
> > > >
> > > > On Thu, Jan 26, 2023 at 4:36 PM Jorge Esteban Quilcate Otoya
> > > >  wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I'd like to call for a vote on KIP-864, which proposes to add
> metrics
> > > to
> > > > > measure end-to-end latency in source and sink connectors.
> > > > >
> > > > > KIP:
> > > > >
> > > >
> > >
> >
>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-864%3A+Add+End-To-End+Late
> ncy+Metrics+to+Connectors
> > > > >
> > > > > Discussion thread:
> > > > > https://lists.apache.org/thread/k6rh2mr7pg94935fgpqw8b5fj308f2n7
> > > > >
> > > > > Many thanks,
> > > > > Jorge.
> > > >
> > >
> >
>
>
>

-- 

Matthew de Detrich

*Aiven Deutschland GmbH*

Immanuelkirchstraße 26, 10405 Berlin

Amtsgericht Charlottenburg, HRB 209739 B

Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen

*m:* +491603708037

*w:* aiven.io *e:* matthew.dedetr...@aiven.io

Re: [ANNOUNCE] New committer: Divij Vaidya

[Edoardo Comar]

Congratulations Divij !


On Wed, 14 Jun 2023 at 10:51, Josep Prat 
wrote:

> Congrats Divij!
>
> On Wed, Jun 14, 2023 at 11:45 AM Lucas Brutschy
>  wrote:
>
> > Congrats!!
> >
> > On Wed, Jun 14, 2023 at 11:02 AM Federico Valeri 
> > wrote:
> > >
> > > Congrats Divij!
> > >
> > > On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya  >
> > wrote:
> > > >
> > > > Thank you everyone! I promise to shoulder this new responsibility to
> > the
> > > > best of my abilities.
> > > >
> > > > --
> > > > Divij Vaidya
> > > >
> > > >
> > > >
> > > > On Wed, Jun 14, 2023 at 4:13 AM ziming deng <
> dengziming1...@gmail.com>
> > > > wrote:
> > > >
> > > > > Congratulations, Divij!
> > > > > Well deserved!
> > > > >
> > > > > --
> > > > > Ziming
> > > > >
> > > > > > On Jun 14, 2023, at 09:41, Luke Chen  wrote:
> > > > > >
> > > > > > Congratulations, Divij!
> > > > > > Well deserved!
> > > > > >
> > > > > > Luke
> > > > > >
> > > > > > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> > > > > >  wrote:
> > > > > >
> > > > > >> Congrats Divij!
> > > > > >>
> > > > > >> On Tue, Jun 13, 2023, 20:27 Philip Nee 
> > wrote:
> > > > > >>
> > > > > >>> Congrats!
> > > > > >>>
> > > > > >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch <
> rha...@gmail.com>
> > > > > wrote:
> > > > > >>>
> > > > >  Congratulations!
> > > > > 
> > > > >  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax <
> > mj...@apache.org>
> > > > > >>> wrote:
> > > > > 
> > > > > > Congrats!
> > > > > >
> > > > > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > > > >> Congratulations Divij!!
> > > > > >>
> > > > > >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > > > >>  wrote:
> > > > > >>>
> > > > > >>> Congratulations Divij.
> > > > > >>>
> > > > > >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna <
> > cado...@apache.org>
> > > > >  wrote:
> > > > > >>>
> > > > >  Hi all,
> > > > > 
> > > > >  The PMC of Apache Kafka is pleased to announce a new Kafka
> > > > > >>> committer
> > > > >  Divij Vaidya.
> > > > > 
> > > > >  Divij's major contributions are:
> > > > > 
> > > > >  GDPR compliance enforcement of kafka-site -
> > > > >  https://issues.apache.org/jira/browse/KAFKA-13868
> > > > > 
> > > > >  Performance improvements:
> > > > > 
> > > > >  Improve performance of VarInt encoding and decoding -
> > > > >  https://github.com/apache/kafka/pull/13312
> > > > > 
> > > > >  Reduce data copy & buffer allocation during decompression
> -
> > > > >  https://github.com/apache/kafka/pull/13135
> > > > > 
> > > > >  He also was heavily involved in the migration to Mockito.
> > > > > 
> > > > >  Furthermore, Divij is very active on the mailing lists as
> > well as
> > > > > >>> in
> > > > >  maintaining and reviewing pull requests.
> > > > > 
> > > > >  Congratulations, Divij!
> > > > > 
> > > > >  Thanks,
> > > > > 
> > > > >  Bruno (on behalf of the Apache Kafka PMC)
> > > > > 
> > > > > 
> > > > >  --
> > > > > >>> Manyanda Chitimbo.
> > > > > >
> > > > > 
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> >
>
>
> --
> [image: Aiven] 
>
> *Josep Prat*
> Open Source Engineering Director, *Aiven*
> josep.p...@aiven.io   |   +491715557497
> aiven.io    |    >
>      <
> https://twitter.com/aiven_io>
> *Aiven Deutschland GmbH*
> Alexanderufer 3-7, 10117 Berlin
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> Amtsgericht Charlottenburg, HRB 209739 B
>

[GitHub] [kafka-site] divijvaidya merged pull request #523: Add Divij Vaidya to committers page

[via GitHub]

divijvaidya merged PR #523:
URL: https://github.com/apache/kafka-site/pull/523


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (KAFKA-15089) Consolidate all the group coordinator configs

[David Jacot (Jira)]

David Jacot created KAFKA-15089:
---

 Summary: Consolidate all the group coordinator configs
 Key: KAFKA-15089
 URL: https://issues.apache.org/jira/browse/KAFKA-15089
 Project: Kafka
  Issue Type: Sub-task
Reporter: David Jacot
Assignee: David Jacot


The group coordinator configurations are defined in KafkaConfig at the moment. 
As KafkaConfig is defined in the core module, we can't pass it to the new java 
modules to pass the configurations along.

A suggestion here is to centralize all the configurations of a module in the 
module itself similarly to what we have do for RemoteLogManagerConfig and 
RaftConfig. We also need a mechanism to add all the properties defined in the 
module to the KafkaConfig's ConfigDef.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [ANNOUNCE] New committer: Divij Vaidya

[Chris Egerton]

Congrats, Divij!

On Wed, Jun 14, 2023 at 9:06 AM Edoardo Comar  wrote:

> Congratulations Divij !
>
>
> On Wed, 14 Jun 2023 at 10:51, Josep Prat 
> wrote:
>
> > Congrats Divij!
> >
> > On Wed, Jun 14, 2023 at 11:45 AM Lucas Brutschy
> >  wrote:
> >
> > > Congrats!!
> > >
> > > On Wed, Jun 14, 2023 at 11:02 AM Federico Valeri  >
> > > wrote:
> > > >
> > > > Congrats Divij!
> > > >
> > > > On Wed, Jun 14, 2023 at 10:02 AM Divij Vaidya <
> divijvaidy...@gmail.com
> > >
> > > wrote:
> > > > >
> > > > > Thank you everyone! I promise to shoulder this new responsibility
> to
> > > the
> > > > > best of my abilities.
> > > > >
> > > > > --
> > > > > Divij Vaidya
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Jun 14, 2023 at 4:13 AM ziming deng <
> > dengziming1...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Congratulations, Divij!
> > > > > > Well deserved!
> > > > > >
> > > > > > --
> > > > > > Ziming
> > > > > >
> > > > > > > On Jun 14, 2023, at 09:41, Luke Chen 
> wrote:
> > > > > > >
> > > > > > > Congratulations, Divij!
> > > > > > > Well deserved!
> > > > > > >
> > > > > > > Luke
> > > > > > >
> > > > > > > On Wed, Jun 14, 2023 at 7:01 AM Viktor Somogyi-Vass
> > > > > > >  wrote:
> > > > > > >
> > > > > > >> Congrats Divij!
> > > > > > >>
> > > > > > >> On Tue, Jun 13, 2023, 20:27 Philip Nee 
> > > wrote:
> > > > > > >>
> > > > > > >>> Congrats!
> > > > > > >>>
> > > > > > >>> On Tue, Jun 13, 2023 at 8:17 PM Randall Hauch <
> > rha...@gmail.com>
> > > > > > wrote:
> > > > > > >>>
> > > > > >  Congratulations!
> > > > > > 
> > > > > >  On Tue, Jun 13, 2023 at 12:48 PM Matthias J. Sax <
> > > mj...@apache.org>
> > > > > > >>> wrote:
> > > > > > 
> > > > > > > Congrats!
> > > > > > >
> > > > > > > On 6/13/23 10:24 AM, Satish Duggana wrote:
> > > > > > >> Congratulations Divij!!
> > > > > > >>
> > > > > > >> On Tue, 13 Jun 2023 at 22:41, Manyanda Chitimbo
> > > > > > >>  wrote:
> > > > > > >>>
> > > > > > >>> Congratulations Divij.
> > > > > > >>>
> > > > > > >>> On Tue 13 Jun 2023 at 17:50, Bruno Cadonna <
> > > cado...@apache.org>
> > > > > >  wrote:
> > > > > > >>>
> > > > > >  Hi all,
> > > > > > 
> > > > > >  The PMC of Apache Kafka is pleased to announce a new
> Kafka
> > > > > > >>> committer
> > > > > >  Divij Vaidya.
> > > > > > 
> > > > > >  Divij's major contributions are:
> > > > > > 
> > > > > >  GDPR compliance enforcement of kafka-site -
> > > > > >  https://issues.apache.org/jira/browse/KAFKA-13868
> > > > > > 
> > > > > >  Performance improvements:
> > > > > > 
> > > > > >  Improve performance of VarInt encoding and decoding -
> > > > > >  https://github.com/apache/kafka/pull/13312
> > > > > > 
> > > > > >  Reduce data copy & buffer allocation during
> decompression
> > -
> > > > > >  https://github.com/apache/kafka/pull/13135
> > > > > > 
> > > > > >  He also was heavily involved in the migration to
> Mockito.
> > > > > > 
> > > > > >  Furthermore, Divij is very active on the mailing lists
> as
> > > well as
> > > > > > >>> in
> > > > > >  maintaining and reviewing pull requests.
> > > > > > 
> > > > > >  Congratulations, Divij!
> > > > > > 
> > > > > >  Thanks,
> > > > > > 
> > > > > >  Bruno (on behalf of the Apache Kafka PMC)
> > > > > > 
> > > > > > 
> > > > > >  --
> > > > > > >>> Manyanda Chitimbo.
> > > > > > >
> > > > > > 
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > >
> >
> >
> > --
> > [image: Aiven] 
> >
> > *Josep Prat*
> > Open Source Engineering Director, *Aiven*
> > josep.p...@aiven.io   |   +491715557497
> > aiven.io    |   <
> https://www.facebook.com/aivencloud
> > >
> >      <
> > https://twitter.com/aiven_io>
> > *Aiven Deutschland GmbH*
> > Alexanderufer 3-7, 10117 Berlin
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
>

Permissions to contribute to Apache Kafka

[Diop, Assane]

Hi Team,



Following are the details for



Wiki id

Email: assane.d...@intel.com

Username: Assane.diop



Jira id

Email: assane.d...@gmail.com

Username: adiop





Thanks,

Assane Diop

Re: [VOTE] KIP-917: Additional custom metadata for remote log segment

[Satish Duggana]

Thanks Ivan for addressing the comments in the KIP, LGTM.

+1

On Tue, 13 Jun 2023 at 18:31, Luke Chen  wrote:
>
> Looks good. Thanks for the update.
>
> On Tue, Jun 13, 2023 at 8:08 PM Ivan Yurchenko 
> wrote:
>
> > Hi all!
> >
> > Thank you for your votes.
> >
> > Based on the proposal of Satish in the discussion thread, I modified the
> > KIP a little bit by lowering the default value of
> > `remote.log.metadata.custom.metadata.max.size` from 10 KiB to 128 bytes. I
> > hope this doesn't change your vote, but feel free to raise your concerns.
> > Thank you!
> >
> > Best,
> > Ivan
> >
> >
> > On Tue, 13 Jun 2023 at 11:09, Josep Prat 
> > wrote:
> >
> > > Hi Ivan,
> > >
> > > Thank you very much for this KIP. +1 (binding) from me.
> > >
> > > Best,
> > >
> > >
> > > On Tue, Jun 13, 2023 at 10:03 AM Luke Chen  wrote:
> > >
> > > > +1 (binding) from me.
> > > >
> > > > Thanks.
> > > > Luke
> > > >
> > > > On Tue, Jun 13, 2023 at 3:44 PM Matthew Benedict de Detrich
> > > >  wrote:
> > > > >
> > > > > +1 (non binding). Thanks for KIP
> > > > >
> > > > > On Tue, Jun 13, 2023 at 3:38 AM Kamal Chandraprakash <
> > > > > kamal.chandraprak...@gmail.com> wrote:
> > > > >
> > > > > > +1 (non-binding). Thanks for the KIP!
> > > > > >
> > > > > > On Mon, Jun 12, 2023, 21:23 Divij Vaidya 
> > > > wrote:
> > > > > >
> > > > > > > I have reviewed the proposal and feel that it would be beneficial
> > > to
> > > > > > > implement.
> > > > > > >
> > > > > > > Vote +1 (non-binding)
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Divij Vaidya
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Jun 12, 2023 at 4:39 PM Ivan Yurchenko <
> > > > ivan0yurche...@gmail.com
> > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > Some interest in KIP-917 was expressed in the discussion thread
> > > > [1].
> > > > > > > After
> > > > > > > > addressing all the comments there, I'm putting it up to a vote.
> > > > > > > > Thanks!
> > > > > > > >
> > > > > > > > Best,
> > > > > > > > Ivan
> > > > > > > >
> > > > > > > > [1]
> > > > https://lists.apache.org/thread/qpccqd3jy5rzvbt5ngtzo3dg9pzp722y
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Matthew de Detrich
> > > > >
> > > > > *Aiven Deutschland GmbH*
> > > > >
> > > > > Immanuelkirchstraße 26, 10405 Berlin
> > > > >
> > > > > Amtsgericht Charlottenburg, HRB 209739 B
> > > > >
> > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > > >
> > > > > *m:* +491603708037
> > > > >
> > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io
> > > >
> > >
> > >
> > > --
> > > [image: Aiven] 
> > >
> > > *Josep Prat*
> > > Open Source Engineering Director, *Aiven*
> > > josep.p...@aiven.io   |   +491715557497
> > > aiven.io    |   <
> > https://www.facebook.com/aivencloud
> > > >
> > >      <
> > > https://twitter.com/aiven_io>
> > > *Aiven Deutschland GmbH*
> > > Alexanderufer 3-7, 10117 Berlin
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> >

[jira] [Created] (KAFKA-15090) Source tasks are no longer stopped on a separate thread

[Chris Egerton (Jira)]

Chris Egerton created KAFKA-15090:
-

 Summary: Source tasks are no longer stopped on a separate thread
 Key: KAFKA-15090
 URL: https://issues.apache.org/jira/browse/KAFKA-15090
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Affects Versions: 3.3.2, 3.3.1, 3.2.3, 3.2.2, 3.4.0, 3.2.1, 3.1.2, 3.0.2, 
3.3.0, 3.1.1, 3.2.0, 3.0.1, 3.0.0, 3.1.0, 3.2.4, 3.1.3, 3.0.3, 3.5.0, 3.4.1, 
3.3.3, 3.6.0, 3.5.1
Reporter: Chris Egerton
Assignee: Chris Egerton


Before [https://github.com/apache/kafka/pull/9669,] in distributed mode, the 
{{SourceTask::stop}} method would be invoked on the herder tick thread, which 
is a separate thread from the dedicated thread which was responsible for 
polling data from the task and producing it to Kafka.

This aligned with the Javadocs for {{{}SourceTask:poll{}}}, which state:
{quote}The task will be stopped on a separate thread, and when that happens 
this method is expected to unblock, quickly finish up any remaining processing, 
and return.
{quote}
However, it came with the downside that the herder's tick thread would be 
blocked until the invocation of {{SourceTask::stop}} completed, which could 
result in major parts of the worker's REST API becoming unavailable and even 
the worker falling out of the cluster.

As a result, in [https://github.com/apache/kafka/pull/9669,] we changed the 
logic for task shutdown to cause {{SourceTask::stop}} to be invoked on the 
dedicated thread for the task (i.e., the one responsible for polling data from 
it and producing that data to Kafka).

This altered the semantics for {{SourceTask:poll}} and {{SourceTask::stop}} and 
may have broken connectors that block during {{poll}} with the expectation that 
{{stop}} can and will be invoked concurrently as a signal that any ongoing 
polls should be interrupted immediately.

Although reverting the fix is likely not a viable option (blocking the herder 
thread on interactions with user-written plugins is high-risk and we have tried 
to eliminate all instances of this where feasible), we may try to restore the 
expected contract by spinning up a separate thread exclusively for invoking 
{{SourceTask::stop}} separately from the dedicated thread for the task and the 
herder's thread.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (KAFKA-15091) Javadocs for SourceTask::commit are incorrect

[Chris Egerton (Jira)]

Chris Egerton created KAFKA-15091:
-

 Summary: Javadocs for SourceTask::commit are incorrect
 Key: KAFKA-15091
 URL: https://issues.apache.org/jira/browse/KAFKA-15091
 Project: Kafka
  Issue Type: Bug
  Components: KafkaConnect
Reporter: Chris Egerton


The Javadocs for {{SourceTask::commit}} state that the method should:
{quote}Commit the offsets, up to the offsets that have been returned by 
[{{poll()}}|https://kafka.apache.org/34/javadoc/org/apache/kafka/connect/source/SourceTask.html#poll()].
{quote}
However, this is obviously incorrect given how the Connect runtime (when not 
configured with exactly-once support for source connectors) performs polling 
and offset commits on separate threads. There's also some extensive discussion 
on the semantics of that method in KAFKA-5716 where it's made clear that 
altering the behavior of the runtime to align with the documented semantics of 
that method is not a viable option.

We should update the Javadocs for this method to state that it does not have 
anything to do with the offsets returned from {{SourceTask:poll}} and is 
instead just a general, periodically-invoked hook to let the task know that an 
offset commit has taken place (but with no guarantees as to which offsets have 
been committed and which ones correspond to still-in-flight records).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [DISCUSS] Partial CI builds - Reducing flakiness with fewer tests

[David Arthur]

>
> > How would we handle commits that break the integration tests? Would
> > we revert commits on trunk, or fix-forward?
>
> This is currently up to committer discretion, and I don't think that
> would change if we were to re-tool the PR builds. In the presence of
> flaky failures, we can't reliably blame failures on particular commits
> without running much more expensive statistical tests.
>

I was more thinking about integration regressions rather than flaky
failures. However, if we're running a module's tests as well as the
"affected modules" tests, then I guess we should
be running the correct integration tests for each PR build. I guess this
gets back to Chris's point about how this approach favors the downstream
modules. Maybe that's unavoidable.

Come to think of it, a similar problem exists with system tests. We don't
run these for each PR (or each trunk commit, or even nightly AFAIK) since
they are prohibitively costly/lengthy to run.
However, they do sometimes find integration regressions that the junit
suite missed. In these cases we only have the choice to fix-forward.


On Tue, Jun 13, 2023 at 12:19 PM Greg Harris 
wrote:

> David,
>
> Thanks for finding that gradle plugin. The `changedModules` mode is
> exactly what I had in mind for fairness to modules earlier in the
> dependency graph.
>
> > if we moved to a policy where PRs only need some of the tests to pass
> > to merge, when would we run the full CI? On each trunk commit (i.e., PR
> > merge)?
>
> In a world where the PR runs includes only the changed modules and
> their dependencies, the full suite should be run for each commit on
> trunk and on release branches. I don't think that optimizing the trunk
> build runtime is of great benefit, and the current behavior seems
> reasonable to continue.
>
> > How would we handle commits that break the integration tests? Would
> > we revert commits on trunk, or fix-forward?
>
> This is currently up to committer discretion, and I don't think that
> would change if we were to re-tool the PR builds. In the presence of
> flaky failures, we can't reliably blame failures on particular commits
> without running much more expensive statistical tests.
>
> One place that I often see flakiness present is in new tests, where
> someone has chosen timeouts which work for them locally and in the PR
> build. After some 10s or 100s of runs, the flakiness becomes evident
> and someone looks into a fix-forward.
> I don't necessarily think I would advocate for a hard revert of an
> entire feature if one of the added tests is flaky, but that's my
> discretion. We can adopt a project policy of reverting whatever we
> can, but I don't think that's a more welcoming or productive project
> than we have now.
>
> Greg
>
> On Tue, Jun 13, 2023 at 7:24 AM David Arthur  wrote:
> >
> > Hey folks, interesting discussion.
> >
> > I came across a Gradle plugin that calculates a DAG of modules based on
> the
> > diff and can run only the affected module's tests or the affected +
> > downstream tests.
> >
> > https://github.com/dropbox/AffectedModuleDetector
> >
> > I tested it out locally, and it seems to work as advertised.
> >
> > Greg, if we moved to a policy where PRs only need some of the tests to
> pass
> > to merge, when would we run the full CI? On each trunk commit (i.e., PR
> > merge)? How would we handle commits that break the integration tests?
> Would
> > we revert commits on trunk, or fix-forward?
> >
> > -David
> >
> >
> > On Thu, Jun 8, 2023 at 2:02 PM Greg Harris  >
> > wrote:
> >
> > > Gaurav,
> > >
> > > The target-determinator is certainly the "off-the-shelf" solution I
> > > expected would be out there. If the project migrates to Bazel I think
> > > that would make the partial builds much easier to implement.
> > > I think we should look into the other benefits of migrating to bazel
> > > to see if it is worth it even if the partial builds feature is decided
> > > against, or after it is reverted.
> > >
> > > Chris,
> > >
> > > > Do you think we should aim to disable
> > > > merges without a full suite of passing CI runs (allowing for
> > > administrative
> > > > override in an emergency)? If so, what would the path be from our
> current
> > > > state to there? What can we do to ensure that we don't get stuck
> relying
> > > on
> > > > a once-temporary aid that becomes effectively permanent?
> > >
> > > Yes I think it would be nice to require a green build to merge,
> > > without excessive merge-queue infrastructure that is more common in
> > > high-volume monorepos.
> > >
> > > 1. We would decide on a sunset date on the partial build indicator, at
> > > which point it will be disabled on trunk and all release branches. I
> > > suspect that a sunset date could be set for 1-3 releases in the
> > > future.
> > > 2. We would enable partial builds. The merge-button would remain
> > > as-is, with the partial build and full-suite indicators both being
> > > visible.
> > > 3. Communication would be sent out to expl

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1922

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 385442 lines...]
[2023-06-14T17:08:26.068Z] [INFO] 
[2023-06-14T17:08:26.068Z] [INFO] --- archetype:2.2:integration-test 
(default-integration-test) @ streams-quickstart-java ---
[2023-06-14T17:08:26.068Z] [INFO] 
[2023-06-14T17:08:26.068Z] [INFO] --- gpg:1.6:sign (sign-artifacts) @ 
streams-quickstart-java ---
[2023-06-14T17:08:26.068Z] [INFO] 
[2023-06-14T17:08:26.068Z] [INFO] --- install:2.5.2:install (default-install) @ 
streams-quickstart-java ---
[2023-06-14T17:08:26.068Z] [INFO] Installing 
/home/jenkins/workspace/Kafka_kafka_trunk/streams/quickstart/java/target/streams-quickstart-java-3.6.0-SNAPSHOT.jar
 to 
/home/jenkins/.m2/repository/org/apache/kafka/streams-quickstart-java/3.6.0-SNAPSHOT/streams-quickstart-java-3.6.0-SNAPSHOT.jar
[2023-06-14T17:08:26.068Z] [INFO] Installing 
/home/jenkins/workspace/Kafka_kafka_trunk/streams/quickstart/java/pom.xml to 
/home/jenkins/.m2/repository/org/apache/kafka/streams-quickstart-java/3.6.0-SNAPSHOT/streams-quickstart-java-3.6.0-SNAPSHOT.pom
[2023-06-14T17:08:26.068Z] [INFO] 
[2023-06-14T17:08:26.068Z] [INFO] --- archetype:2.2:update-local-catalog 
(default-update-local-catalog) @ streams-quickstart-java ---
[2023-06-14T17:08:26.068Z] [INFO] 

[2023-06-14T17:08:26.068Z] [INFO] Reactor Summary for Kafka Streams :: 
Quickstart 3.6.0-SNAPSHOT:
[2023-06-14T17:08:26.068Z] [INFO] 
[2023-06-14T17:08:26.068Z] [INFO] Kafka Streams :: Quickstart 
 SUCCESS [  2.545 s]
[2023-06-14T17:08:26.068Z] [INFO] streams-quickstart-java 
 SUCCESS [  1.350 s]
[2023-06-14T17:08:26.068Z] [INFO] 

[2023-06-14T17:08:26.068Z] [INFO] BUILD SUCCESS
[2023-06-14T17:08:26.068Z] [INFO] 

[2023-06-14T17:08:26.068Z] [INFO] Total time:  4.271 s
[2023-06-14T17:08:26.068Z] [INFO] Finished at: 2023-06-14T17:08:25Z
[2023-06-14T17:08:26.068Z] [INFO] 

[2023-06-14T17:08:26.068Z] [WARNING] 
[2023-06-14T17:08:26.068Z] [WARNING] Plugin validation issues were detected in 
7 plugin(s)
[2023-06-14T17:08:26.068Z] [WARNING] 
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-remote-resources-plugin:1.5
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-install-plugin:2.5.2
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-archetype-plugin:2.2
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-resources-plugin:2.7
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-clean-plugin:3.0.0
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-site-plugin:3.5.1
[2023-06-14T17:08:26.068Z] [WARNING]  * 
org.apache.maven.plugins:maven-gpg-plugin:1.6
[2023-06-14T17:08:26.068Z] [WARNING] 
[2023-06-14T17:08:26.068Z] [WARNING] For more or less details, use 
'maven.plugin.validation' property with one of the values (case insensitive): 
[BRIEF, DEFAULT, VERBOSE]
[2023-06-14T17:08:26.068Z] [WARNING] 
[Pipeline] dir
[2023-06-14T17:08:26.590Z] Running in 
/home/jenkins/workspace/Kafka_kafka_trunk/streams/quickstart/test-streams-archetype
[Pipeline] {
[Pipeline] sh
[2023-06-14T17:08:29.020Z] + echo Y
[2023-06-14T17:08:29.020Z] + mvn archetype:generate -DarchetypeCatalog=local 
-DarchetypeGroupId=org.apache.kafka 
-DarchetypeArtifactId=streams-quickstart-java -DarchetypeVersion=3.6.0-SNAPSHOT 
-DgroupId=streams.examples -DartifactId=streams.examples -Dversion=0.1 
-Dpackage=myapps
[2023-06-14T17:08:29.965Z] [INFO] Scanning for projects...
[2023-06-14T17:08:31.932Z] [INFO] 
[2023-06-14T17:08:31.932Z] [INFO] --< 
org.apache.maven:standalone-pom >---
[2023-06-14T17:08:31.932Z] [INFO] Building Maven Stub Project (No POM) 1
[2023-06-14T17:08:31.932Z] [INFO] [ pom 
]-
[2023-06-14T17:08:31.932Z] [INFO] 
[2023-06-14T17:08:31.932Z] [INFO] >>> archetype:3.2.1:generate (default-cli) > 
generate-sources @ standalone-pom >>>
[2023-06-14T17:08:31.932Z] [INFO] 
[2023-06-14T17:08:31.932Z] [INFO] <<< archetype:3.2.1:generate (default-cli) < 
generate-sources @ standalone-pom <<<
[2023-06-14T17:08:31.932Z] [INFO] 
[2023-06-14T17:08:31.932Z] [INFO] 
[2023-06-14T17:08:31.932Z] [INFO] --- archetype:3.2.1:generate (default-cli) @ 
standalone-pom ---
[2023-06-14T17:08:32.944Z] [INFO] Generating project in Interactive mode
[2023-06-14T17:08:34.135Z] [WARNING] Archetype not found in any catalog. 
Falling back to central repository.
[2023-06-14T17:08:34.135Z] [WARNING] Add a repository with id 'archetype' in 
your settings.xml if archetype's repository is

Re: [VOTE] KIP-858: Handle JBOD broker disk failure in KRaft

[Colin McCabe]

Hi Igor,

Thanks for all your work on this! You've really done a lot to push it over the 
finish line. It will be awesome to see this coming to a 3.x release soon.

I did a preliminary pass today. Can I please ask that you give us two weeks 
before you close the vote, since it's such a big change?

I have a few major concerns that are top of mind. Firstly, I'd like to avoid 
creating a big performance impact on clusters that don't use JBOD. Secondly, I 
wanted to dig into the broker/controller interactions here a bit. Finally, 
wanted to talk about meta.properties.

So, let me start by discussing the performance impact on non-JBOD clusters. 
UUIDs are big (8 bytes) and adding 3 of them to the average partition 
assignment will add 24 bytes to PartitionRecord. The size of PartitionRecord is 
critical since a big cluster will have lots and lots of partitions. So I think 
24 extra bytes per partition is a lot of overhead to pay for systems that 
aren't using JBOD.

I think we can avoid this by using a tagged field. Then we can say that if the 
driectory UUID information isn't present, we assume that the partition is in 
the directory corresponding to UUID 0. Then, we can also update the formatting 
tool (and auto-id-generator, etc.) to honor this, setting the first directory 
in the system to UUID 0. Subsequent ones will get a random, non-zero ID, of 
course.

I think this gives us the best of both worlds. There is no performance impact 
on non-JBOD, but for JBOD systems, we have a unique UUID for each directory. It 
also probably makes upgrade easier since we start in a valid state 
automatically (everything in directory 0).

The next thing I wanted to talk about was broker/controller interaction. After 
reading the KIP, it wasn't clear to me whether the controller would be 
responsible for picking a storage directory for new partitions, or whether the 
broker would be. A few times in the doc, you suggest that if the broker has the 
partition in the "wrong" directory, it should move it. That would suggest the 
controller is in control.

If the controller is in control, then we should describe what its policy is for 
picking a storage directory for new replicas. Probably choosing randomly is 
fine as a start.

With controller-side placement, we probably also want a mechanism for the 
broker to be able to ask the controller to stop placing replicas in a certain 
directory, even if it is still working. This would be used if a directory 
starts filling up. I suppose this could be a follow-on KIP as well. However, if 
we don't have this, then we are constraining people to use only roughly equally 
sized directories, and we should note that.

I'd like to understand how directory reassignment will work in this new system. 
In ZK mode, this is done in an entirely broker-side way. The client sends an 
RPC asking the broker to move a replica between directories, and it does so, 
without involving the controller. Are we going to support the same kind of 
system? Or do we want this as well to be controller side?

There are some problems to solve if we want to make inter-directory 
reassignment initiated by the controller, without the broker in the loop. If 
implemented naively, we would violate our durability gauratees.

For example, let's say the client asks the controller to move a replica on 
broker A from directory X to Y. But then before broker learns about this move, 
the broker restarts without directory X (perhaps it has failed, or been 
reconfigured away.) Now the broker is left with just instructions to create the 
replica on directory Y. But it will create an empty replica, which could lead 
to us "going backwards" if the replica was in the ISR.

We can avoid this problem in a few ways. One is to store a "previous log dir 
UUID" in PartitionRecord. But this is kind of awkward because it increases 
metadata size, and the state must be managed. A second way is to have the 
broker perform the move and then ask the controller to "finalize" it in the 
metadata. I think this was your intention with AssignReplicasToDirsRequest, but 
we should spell this out a bit more clearly. If that's the case, then 
AssignReplicasToDirsRequest can only be made by brokers, not be clients.

 A diagram of how a partition move progresses (starting with the client 
initiating it) would help here.

There are a few other smaller comments I had. In PartitionRecord, I would 
prefer a new (tagged) array for replica UUIDs, rather than creating the 
ReplicaAssignment array.

I think the offline log dirs array in BrokerHeartbeatRequest should be tagged 
as well, to conserve space (heartbeats are sent often, and directory failures 
are rare.) Also OfflineLogDirs seems like a better name than LogDirsOfflined 
(and more consistent with the registration request RPC).

The last thing I wanted to mention in this overview email was meta.properties. 
There is some ambiguity with directory.ids because if we can't find one of the 
specified IDs, it cou

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1923

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-15092) KafkaClusterTestKit in test jar depends on MockFaultHandler

[Gary Russell (Jira)]

Gary Russell created KAFKA-15092:


 Summary: KafkaClusterTestKit in test jar depends on 
MockFaultHandler
 Key: KAFKA-15092
 URL: https://issues.apache.org/jira/browse/KAFKA-15092
 Project: Kafka
  Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Gary Russell


{noformat}
java.lang.NoClassDefFoundError: org/apache/kafka/server/fault/MockFaultHandler
at 
kafka.testkit.KafkaClusterTestKit$SimpleFaultHandlerFactory.(KafkaClusterTestKit.java:119)
at 
kafka.testkit.KafkaClusterTestKit$Builder.(KafkaClusterTestKit.java:143)
{noformat}

MockFaultHandler is missing from the test jar.

This PR https://github.com/apache/kafka/pull/13375/files seems to work around 
it by adding the {code}server-common sourcesets.test.output{code} to the class 
path.

The class needs to be available for third parties to create an embedded KRaft 
broker.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1924

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 576515 lines...]
[2023-06-14T23:34:11.233Z] 
[2023-06-14T23:34:11.233Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > VersionedKeyValueStoreIntegrationTest > 
shouldManualUpgradeFromNonVersionedTimestampedToVersioned PASSED
[2023-06-14T23:34:11.233Z] 
[2023-06-14T23:34:11.233Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > HandlingSourceTopicDeletionIntegrationTest > 
shouldThrowErrorAfterSourceTopicDeleted STARTED
[2023-06-14T23:34:16.699Z] 
[2023-06-14T23:34:16.699Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > HandlingSourceTopicDeletionIntegrationTest > 
shouldThrowErrorAfterSourceTopicDeleted PASSED
[2023-06-14T23:34:19.551Z] 
[2023-06-14T23:34:19.551Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorLargeNumConsumers STARTED
[2023-06-14T23:34:52.712Z] 
[2023-06-14T23:34:52.712Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorLargeNumConsumers PASSED
[2023-06-14T23:34:52.712Z] 
[2023-06-14T23:34:52.712Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorLargePartitionCount STARTED
[2023-06-14T23:35:04.627Z] 
[2023-06-14T23:35:04.627Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorLargePartitionCount PASSED
[2023-06-14T23:35:04.627Z] 
[2023-06-14T23:35:04.627Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorManyThreadsPerClient STARTED
[2023-06-14T23:35:05.735Z] 
[2023-06-14T23:35:05.735Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorManyThreadsPerClient PASSED
[2023-06-14T23:35:05.735Z] 
[2023-06-14T23:35:05.735Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyStandbys STARTED
[2023-06-14T23:35:13.213Z] 
[2023-06-14T23:35:13.213Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyStandbys PASSED
[2023-06-14T23:35:13.213Z] 
[2023-06-14T23:35:13.213Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyThreadsPerClient STARTED
[2023-06-14T23:35:14.450Z] 
[2023-06-14T23:35:14.450Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorManyThreadsPerClient PASSED
[2023-06-14T23:35:14.450Z] 
[2023-06-14T23:35:14.450Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyThreadsPerClient STARTED
[2023-06-14T23:35:14.450Z] 
[2023-06-14T23:35:14.450Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyThreadsPerClient PASSED
[2023-06-14T23:35:14.450Z] 
[2023-06-14T23:35:14.450Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargePartitionCount STARTED
[2023-06-14T23:35:51.648Z] 
[2023-06-14T23:35:51.648Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorLargePartitionCount PASSED
[2023-06-14T23:35:51.648Z] 
[2023-06-14T23:35:51.648Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargePartitionCount STARTED
[2023-06-14T23:36:19.517Z] 
[2023-06-14T23:36:19.517Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testStickyTaskAssignorLargePartitionCount PASSED
[2023-06-14T23:36:19.517Z] 
[2023-06-14T23:36:19.517Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyStandbys STARTED
[2023-06-14T23:36:25.074Z] 
[2023-06-14T23:36:25.074Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testFallbackPriorTaskAssignorManyStandbys PASSED
[2023-06-14T23:36:25.074Z] 
[2023-06-14T23:36:25.074Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvailabilityTaskAssignorManyStandbys STARTED
[2023-06-14T23:36:54.630Z] 
[2023-06-14T23:36:54.630Z] Gradle Test Run :streams:integrationTest > Gradle 
Test Executor 180 > StreamsAssignmentScaleTest > 
testHighAvaila

Re: Permissions to contribute to Apache Kafka

[Luke Chen]

Hi Assane,

Your accounts are all set.

Thanks
Luke

On Wed, Jun 14, 2023 at 10:39 PM Diop, Assane  wrote:

> Hi Team,
>
>
>
> Following are the details for
>
>
>
> Wiki id
>
> Email: assane.d...@intel.com
>
> Username: Assane.diop
>
>
>
> Jira id
>
> Email: assane.d...@gmail.com
>
> Username: adiop
>
>
>
>
>
> Thanks,
>
> Assane Diop
>
>

[jira] [Resolved] (KAFKA-14709) Move content in connect/mirror/README.md to the docs

[Luke Chen (Jira)]

 [ 
https://issues.apache.org/jira/browse/KAFKA-14709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Luke Chen resolved KAFKA-14709.
---
Fix Version/s: 3.6.0
   Resolution: Fixed

> Move content in connect/mirror/README.md to the docs
> 
>
> Key: KAFKA-14709
> URL: https://issues.apache.org/jira/browse/KAFKA-14709
> Project: Kafka
>  Issue Type: Improvement
>  Components: docs, mirrormaker
>Reporter: Mickael Maison
>Assignee: Gantigmaa Selenge
>Priority: Major
> Fix For: 3.6.0
>
>
> We should move all the content in 
> https://github.com/apache/kafka/blob/trunk/connect/mirror/README.md to the 
> relevant doc sections. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1925

[Apache Jenkins Server]

See