[PR] MINOR: add v3.9.1 in download page [kafka-site]

[via GitHub]

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

   add v3.9.1 in download page


-- 
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-19318) Zookeeper-Kraft failing migration - RPC got timed out before it could be sent

[dennis lucero (Jira)]

dennis lucero created KAFKA-19318:
-

 Summary: Zookeeper-Kraft failing migration - RPC got timed out 
before it could be sent
 Key: KAFKA-19318
 URL: https://issues.apache.org/jira/browse/KAFKA-19318
 Project: Kafka
  Issue Type: Bug
  Components: kraft
Affects Versions: 3.6.1, 3.6.2, 3.7.0
Reporter: dennis lucero
 Fix For: 3.7.1


Despite several attempts to migrate from Zookeeper cluster to Kraft, it failed 
to properly migrate.

We spawn a need cluster fully healthy with 3 Kafka nodes connected to 3 
Zookeeper nodes. 3 new Kafka nodes are there for the new controllers.
It was tested with Kafka 3.6.1, 3.6.2 and 3.7.0.

it might be linked to KAFKA-15330.

The controllers are started without issue. When the brokers are then configured 
for the migration, the migration is not starting. Once the last broker is 
restarted, we got the following logs.
{code:java}
[2024-06-03 15:11:48,192] INFO [ReplicaFetcherThread-0-11]: Stopped 
(kafka.server.ReplicaFetcherThread)
[2024-06-03 15:11:48,193] INFO [ReplicaFetcherThread-0-11]: Shutdown completed 
(kafka.server.ReplicaFetcherThread)
{code}
Then we only get the following every 30s
{code:java}
[2024-06-03 15:12:04,163] INFO [BrokerLifecycleManager id=12 isZkBroker=true] 
Unable to register the broker because the RPC got timed out before it could be 
sent. (kafka.server.BrokerLifecycleManager)
[2024-06-03 15:12:34,297] INFO [BrokerLifecycleManager id=12 isZkBroker=true] 
Unable to register the broker because the RPC got timed out before it could be 
sent. (kafka.server.BrokerLifecycleManager)
[2024-06-03 15:13:04,536] INFO [BrokerLifecycleManager id=12 isZkBroker=true] 
Unable to register the broker because the RPC got timed out before it could be 
sent. (kafka.server.BrokerLifecycleManager){code}

The config on the controller node is the following
{code:java}
kafka0202e1 ~]$  sudo grep -v '^\s*$\|^\s*\#' /etc/kafka/server.properties  | 
grep -v password | sort
advertised.host.name=kafka0202e1.ahub.sb.eu.ginfra.net
broker.rack=e1
controller.listener.names=CONTROLLER
controller.quorum.voters=2...@kafka0202e1.ahub.sb.eu.ginfra.net:9093,2...@kafka0202e2.ahub.sb.eu.ginfra.net:9093,2...@kafka0202e3.ahub.sb.eu.ginfra.net:9093
default.replication.factor=3
delete.topic.enable=false
group.initial.rebalance.delay.ms=3000
inter.broker.protocol.version=3.7
listeners=CONTROLLER://kafka0202e1.ahub.sb.eu.ginfra.net:9093
listener.security.protocol.map=CONTROLLER:SSL,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
log.dirs=/data/kafka
log.message.format.version=3.6
log.retention.check.interval.ms=30
log.retention.hours=240
log.segment.bytes=1073741824
min.insync.replicas=2
node.id=20
num.io.threads=8
num.network.threads=3
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=3
process.roles=controller
security.inter.broker.protocol=SSL
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
socket.send.buffer.bytes=102400
ssl.cipher.suites=TLS_AES_256_GCM_SHA384
ssl.client.auth=required
ssl.enabled.protocols=TLSv1.3
ssl.endpoint.identification.algorithm=HTTPS
ssl.keystore.location=/etc/kafka/ssl/keystore.ts
ssl.keystore.type=JKS
ssl.secure.random.implementation=SHA1PRNG
ssl.truststore.location=/etc/kafka/ssl/truststore.ts
transaction.state.log.min.isr=3
transaction.state.log.replication.factor=3
unclean.leader.election.enable=false
zookeeper.connect=10.135.65.199:2181,10.133.65.199:2181,10.137.64.56:2181,
zookeeper.metadata.migration.enable=true
 {code}

The config on the broker node is the following
{code}
$ sudo grep -v '^\s*$\|^\s*\#' /etc/kafka/server.properties  | grep -v password 
| sort
advertised.host.name=kafka0201e3.ahub.sb.eu.ginfra.net
advertised.listeners=SSL://kafka0201e3.ahub.sb.eu.ginfra.net:9092
broker.id=12
broker.rack=e3
controller.listener.names=CONTROLLER # added once all controllers were started
controller.quorum.voters=2...@kafka0202e1.ahub.sb.eu.ginfra.net:9093,2...@kafka0202e2.ahub.sb.eu.ginfra.net:9093,2...@kafka0202e3.ahub.sb.eu.ginfra.net:9093
 # added once all controllers were started
default.replication.factor=3
delete.topic.enable=false
group.initial.rebalance.delay.ms=3000
inter.broker.protocol.version=3.7
listener.security.protocol.map=CONTROLLER:SSL,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
listeners=SSL://kafka0201e3.ahub.sb.eu.ginfra.net:9092
log.dirs=/data/kafka
log.retention.check.interval.ms=30
log.retention.hours=240
log.segment.bytes=1073741824
min.insync.replicas=2
num.io.threads=8
num.network.threads=3
num.partitions=1
num.recovery.threads.per.data.dir=1
offsets.topic.replication.factor=3
security.inter.broker.protocol=SSL
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
socket.send.buffer.bytes=102400
ssl.cipher.suites=TLS_AES_256_GCM_SHA384
ssl.client.auth=required
ssl.e

Re: Missing Response Formats in Kafka Protocol Guide

[Andy Li]

The PR was merged by Chia-Ping.

Guys, do you know what's the next scheduled date when
https://kafka.apache.org/protocol.html will be updated? Thanks!

- Andy


On Tue, 20 May 2025 at 11:44, Andy Li  wrote:

> PR opened: https://github.com/apache/kafka/pull/19769 Thanks!
>
> - Andy
>
>
> On Tue, 20 May 2025 at 11:35, Ziming Deng 
> wrote:
>
>> Can you submit a PR to fix it? Thank you!
>>
>> > On May 20, 2025, at 11:26, Andy Li  wrote:
>> >
>> > Hey Ziming,
>> >
>> > Thanks for pointing to org.apache.kafka.common.protocol.Protocal.main!
>> >
>> > It seem that this line should use `<=` instead `<`:
>> >
>> > Protocol.java <
>> https://github.com/apache/kafka/blob/cff10e654149ed2d4924235a15156d4bc0bf7b4a/clients/src/main/java/org/apache/kafka/common/protocol/Protocol.java#L211
>> >
>> >
>> >
>> >
>> > - Andy
>> >
>> >
>> > On Tue, 20 May 2025 at 10:38, Ziming Deng > > wrote:
>> >> Hello Andi,
>> >> This page content is generated from
>> org.apache.kafka.common.protocol.Protocal.main , can you help to check it?
>> >>
>> >> > On May 20, 2025, at 09:13, Andy Li > a...@codecrafters.io>> wrote:
>> >> >
>> >> > Hi Kafka Team,
>> >> >
>> >> > I noticed a couple of response formats missing from the Kafka
>> protocol guide
>> >> > :
>> >> >
>> >> > - *ApiVersions Response (Version: 4)* — Only versions 0–3 are
>> documented,
>> >> > though version 4 of the request is included.
>> >> >
>> >> > - *DescribeTopicPartitions Response* — Not listed at all.
>> >> >
>> >> > - *Fetch Response (Version: 17)* — Only versions 4–16 are documented,
>> >> > though version 17 of the request is included.
>> >> >
>> >> > Just wanted to flag in case this was unintentional. Thanks for all
>> the
>> >> > great work on Kafka!
>> >> >
>> >> > Best,
>> >> >
>> >> > Andy Li
>> >>
>>
>>

Re: Missing Response Formats in Kafka Protocol Guide

[ziming deng]

I don’t have experience generating content for kafka.apache.org , but according 
to the content of https://github.com/apache/kafka-site , I guess it will be 
regenerated the next time the kafka-site repository is updated, but I’m not 
sure about it.

-
Ziming

> On May 21, 2025, at 9:17 AM, Andy Li  wrote:
> 
> The PR was merged by Chia-Ping.
> 
> Guys, do you know what's the next scheduled date when
> https://kafka.apache.org/protocol.html will be updated? Thanks!
> 
> - Andy
> 
> 
> On Tue, 20 May 2025 at 11:44, Andy Li  wrote:
> 
>> PR opened: https://github.com/apache/kafka/pull/19769 Thanks!
>> 
>> - Andy
>> 
>> 
>> On Tue, 20 May 2025 at 11:35, Ziming Deng 
>> wrote:
>> 
>>> Can you submit a PR to fix it? Thank you!
>>> 
 On May 20, 2025, at 11:26, Andy Li  wrote:
 
 Hey Ziming,
 
 Thanks for pointing to org.apache.kafka.common.protocol.Protocal.main!
 
 It seem that this line should use `<=` instead `<`:
 
 Protocol.java <
>>> https://github.com/apache/kafka/blob/cff10e654149ed2d4924235a15156d4bc0bf7b4a/clients/src/main/java/org/apache/kafka/common/protocol/Protocol.java#L211
 
 
 
 
 - Andy
 
 
 On Tue, 20 May 2025 at 10:38, Ziming Deng >> > wrote:
> Hello Andi,
> This page content is generated from
>>> org.apache.kafka.common.protocol.Protocal.main , can you help to check it?
> 
>> On May 20, 2025, at 09:13, Andy Li >> a...@codecrafters.io>> wrote:
>> 
>> Hi Kafka Team,
>> 
>> I noticed a couple of response formats missing from the Kafka
>>> protocol guide
>> :
>> 
>> - *ApiVersions Response (Version: 4)* — Only versions 0–3 are
>>> documented,
>> though version 4 of the request is included.
>> 
>> - *DescribeTopicPartitions Response* — Not listed at all.
>> 
>> - *Fetch Response (Version: 17)* — Only versions 4–16 are documented,
>> though version 17 of the request is included.
>> 
>> Just wanted to flag in case this was unintentional. Thanks for all
>>> the
>> great work on Kafka!
>> 
>> Best,
>> 
>> Andy Li
> 
>>> 
>>> 

Re: [DISCUSS] KIP-1153: Extending support for Microsecond Precision for Kafka Connect

[pritam kumar]

Hi Kafka Community,
If there is no other feedback. I would like to start a VOTE.

On Mon, May 19, 2025 at 6:51 PM pritam kumar 
wrote:

> Hi Kafka Community,
> Here is the KIP LInk ->
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=347933282
>
> On Mon, May 19, 2025 at 6:47 PM pritam kumar 
> wrote:
>
>> Hi Kafka Community,
>>
>> Could you please review this KIP proposal when you have a chance?
>>
>> Thank you,
>> Pritam
>>
>>
>> On Sat, May 3, 2025 at 10:53 PM pritam kumar 
>> wrote:
>>
>>> Hi Chris,
>>> Can you please review this one too?
>>>
>>> On Sat, Apr 5, 2025 at 7:00 AM pritam kumar 
>>> wrote:
>>>
 Hi Kafka Community,
 Sorry due to some changes I had to change the link to the kip.
 Here is the updated KIP link:
 https://cwiki.apache.org/confluence/display/KAFKA/KIP-1154%3A+Extending+support+for+Microsecond+Precision+for+Kafka+Connect

 On Sat, Apr 5, 2025 at 12:14 AM pritam kumar 
 wrote:

> Hi Kafka Community,
>
> I’d like to start a discussion on KIP-1153: Extending Support for
> Microsecond Precision for Kafka Connect
> 
> .
>
> The primary motivation behind this KIP is to enhance the precision of
> timestamp handling in Kafka Connect. Currently, Kafka Connect is limited 
> to
> millisecond-level precision for timestamps. However, many modern data
> formats and platforms have moved beyond this limitation:
>
>-
>
>Formats such as *Avro*, *Parquet*, and *ORC* support microsecond
>(and even nanosecond) precision. For example, Avro specifies support 
> for
>timestamp-micros (spec link
>).
>-
>
>Sink systems like *Apache Iceberg*, *Delta Lake*, and *Apache Hudi*
> offer *microsecond and nanosecond precision* for time-based
>fields, making millisecond precision inadequate for accurate data
>replication and analytics in some use cases.
>
> This gap can lead to *loss of precision* when transferring data
> through Kafka Connect, especially when interacting with systems that 
> depend
> on high-resolution timestamps for change tracking, event ordering, or
> deduplication.
>
> The goal of this KIP is to:
>
>-
>
>Introduce microsecond-level timestamp handling in Kafka Connect
>schema and data representation.
>-
>
>Ensure connectors (both source and sink) can leverage this
>precision when supported by the underlying data systems.
>-
>
>Maintain backward compatibility with existing millisecond-based
>configurations and data.
>
> We welcome community feedback on:
>
>-
>
>Potential implementation concerns or edge cases we should address
>-
>
>Suggestions for schema enhancements or conversion strategies
>-
>
>Impacts on connector compatibility and testing
>
> Looking forward to your thoughts and input on this proposal!
>
> Thanks.
>  Link to the KIP.
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1153%3A+Extending+Support+for+Microsecond+Precision+for+Kafka+Connect
> 
>
>

Re: [PR] MINOR: Add 3.9.1 blog post [kafka-site]

[via GitHub]

showuon merged PR #688:
URL: https://github.com/apache/kafka-site/pull/688


-- 
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: [PR] MINOR: Update 3.9.1 site [kafka-site]

[via GitHub]

showuon merged PR #687:
URL: https://github.com/apache/kafka-site/pull/687


-- 
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: [PR] MINOR: add v3.9.1 in download page [kafka-site]

[via GitHub]

showuon merged PR #689:
URL: https://github.com/apache/kafka-site/pull/689


-- 
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

[ANNOUNCE] Apache Kafka 3.9.1

[TengYao Chi]

The Apache Kafka community is pleased to announce the release for
Apache Kafka 3.9.1

This bug-fix release has several fixes, and most importantly, it adds
Java 23 support.

All of the changes in this release can be found in the release notes:
https://www.apache.org/dist/kafka/3.9.1/RELEASE_NOTES.html


An overview of the release can be found in our announcement blog post:
https://kafka.apache.org/blog#apache_kafka_391_release_announcement

You can download the source and binary release (Scala 2.12 / 2.13) from:
https://kafka.apache.org/downloads#3.9.1

---


Apache Kafka is a distributed streaming platform with four core APIs:

** The Producer API allows an application to publish a stream of records to
one or more Kafka topics.

** The Consumer API allows an application to subscribe to one or more
topics and process the stream of records produced to them.

** The Streams API allows an application to act as a stream processor,
consuming an input stream from one or more topics and producing an
output stream to one or more output topics, effectively transforming the
input streams to output streams.

** The Connector API allows building and running reusable producers or
consumers that connect Kafka topics to existing applications or data
systems. For example, a connector to a relational database might
capture every change to a table.


With these APIs, Kafka can be used for two broad classes of applications:

** Building real-time streaming data pipelines that reliably get data
between systems or applications.

** Building real-time streaming applications that transform or react
to the streams of data.


Apache Kafka is in use at large and small companies worldwide, including
Capital One, Goldman Sachs, ING, LinkedIn, Netflix, Pinterest, Rabobank,
Target, The New York Times, Uber, Yelp, and Zalando, among others.

A big thank you for the following 57 contributors to this release!
(Please report an unintended omission)
Alieh Saeedi, Almog Gavra, Alyssa Huang, Andrew Schofield, Anna Sophie
Blee-Goldman, Ayoub Omari, Azhar Ahmed, Bill Bejeck, Bruno Cadonna,
Chia-Ping Tsai, Colin Patrick McCabe, Colt McNealy, David Arthur,
David Jacot, Dimitar Dimitrov, Divij Vaidya, Edoardo Comar, Federico
Valeri, Florian Hussonnois, Greg Harris, Guozhang Wang, Hailey Ni,
Ismael Juma, Jeff Kim, Jhen-Yung Hsu, Jonah Hooper, Jorge Esteban
Quilcate Otoya, Josep Prat, José Armando García Sancio, Jun Rao,
Justin Lee, Justine Olshan, Kamal Chandraprakash, Ken Huang, Kirk
True, Kuan-Po Tseng, Laxman Ch, Lianet Magrans, Logan Zhu, Lucas
Brutschy, Luke Chen, Manikumar Reddy, Martin Sillence, Matthias J.
Sax, Mickael Maison, Ming-Yen Chung, Nick Telford, nilmadhab mondal,
Parker Chang, PoAn Yang, Sean Quah, Sebastien Viale, ShivsundarR, Stig
Døssing, TaiJuWu, TengYao Chi, Vedarth Sharma, Ziming Deng

We welcome your help and feedback. For more information on how to
report problems, and to get involved, visit the project website at
https://kafka.apache.org/

Thank you!


Regards,

Luke Chen, TengYao Chi
Release Managers for Apache Kafka 3.9.1

Re: [RESULTS] [VOTE] Release Kafka version 3.9.1

[TengYao Chi]

Hi Satya

This thread is used to announce that 3.9.1-rc2 has been accepted.
Another email will announce the 3.9.1 release; after that, it will be
available on the official website.

Cheers,
TengYao

Satya Bezawada  於 2025年5月20日 週二 下午11:48寫道：

> Wondering why this release is not available on the official downloads page
> yet, https://kafka.apache.org/downloads
> [http://apache-kafka.org/images/apache-kafka.png]<
> https://kafka.apache.org/downloads>
> Apache Kafka
> Apache Kafka: A Distributed Streaming Platform.
> kafka.apache.org
>
> 
> From: TengYao Chi 
> Sent: Sunday, May 18, 2025 12:05 PM
> To: dev@kafka.apache.org ;
> kafka-clie...@googlegroups.com ;
> us...@kafka.apache.org 
> Subject: [RESULTS] [VOTE] Release Kafka version 3.9.1
>
> This vote passes with 8 +1 votes (3 bindings) and no 0 or -1 votes.
>
> +1 votes
> PMC Members:
> * Josep Prat
> * Justine Olshan
> * Mickael Maison
>
> Committers:
> N/A
>
> Community:
> * Paolo Patierno
> * Kuan Po Tseng
>
> * Jiunn-Yang Huang
>
> * PoAn Yang
>
> * Hong-Yi Chen
>
> 0 votes * No votes -1 votes * No votes Vote thread:
>
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F5q9337moctfl6y3rdpbwcldf9bm6o1ml&data=05%7C02%7C%7C7adbe8f966ed4c8cbca108dd96260ca6%7C84df9e7fe9f640afb435%7C1%7C0%7C638831812352614023%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qHcqyxXWBu0Yf79M%2FIatvr3bhhEd9kbR4wtgOlz4hfw%3D&reserved=0
>  I'll
> continue with the release process and the release announcement will follow
> in the next few days. TengYao Chi
>

[PR] Update Procotol Guide [kafka-site]

[via GitHub]

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

   Update generated/protocol_messages.html after 
https://github.com/apache/kafka/pull/19769


-- 
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-1179: Introduce remote.log.manager.follower.thread.pool.size config

[Kuan-Po Tseng]

Hi Luke

Thanks for your feedback!

L1, L2: The logic for
`RemoteLogManagerConfig#remoteLogManagerFollowerThreadPoolSize` is shown
below.
```
public int remoteLogManagerFollowerThreadPoolSize() {
if
(config.originals().containsKey(REMOTE_LOG_MANAGER_FOLLOWER_THREAD_POOL_SIZE_PROP))
{
return
config.getInt(REMOTE_LOG_MANAGER_FOLLOWER_THREAD_POOL_SIZE_PROP);
} else {
return config.getInt(REMOTE_LOG_MANAGER_THREAD_POOL_SIZE_PROP);
}
}
```
This method first checks whether the user has explicitly set
remote.log.manager.follower.thread.pool.size.
If not, it falls back to remote.log.manager.thread.pool.size.
So remote.log.manager.follower.thread.pool.size always takes precedence,
regardless of whether it's configured statically in the broker config file
or dynamically at runtime.

For example, if the user sets remote.log.manager.thread.pool.size=10 and
later
dynamically configures remote.log.manager.follower.thread.pool.size=8, the
follower thread pool size will be 8.

I’ll also update this example in the "Compatibility, Deprecation, and
Migration Plan" section.

Best,
Kuan-Po





On Tue, May 20, 2025 at 10:43 AM Luke Chen  wrote:

> Hi Kuan-Po,
>
> Thanks for the KIP!
>
> Questions:
> 1. If `remote.log.manager.thread.pool.size` is set and
> `remote.log.manager.follower.thread.pool.size` is not set, we will still
> honor the setting in `remote.log.manager.thread.pool.size`, right? We
> should add in KIP to make it clear.
>
> 2. Suppose `remote.log.manager.thread.pool.size=10` and
> `remote.log.manager.follower.thread.pool.size` is not set, could we do
> dynamically config change to `remote.log.manager.follower.thread.pool.size`
> config? The value of will be `remote.log.manager.follower.thread.pool.size`
> 10 or default 2?
>
> Thank you.
> Luke
>
>
> On Tue, May 20, 2025 at 9:28 AM Kuan-Po Tseng  wrote:
>
> > Hello everyone,
> >
> > Just giving this thread a little nudge. If there’s no more feedback, I’ll
> > kick off the vote tomorrow.
> > Also, thanks to Kamal for reviewing this KIP!
> >
> > Best Regards,
> > Kuan-Po
> >
> > On Mon, May 19, 2025 at 11:16 PM Kamal Chandraprakash <
> > kamal.chandraprak...@gmail.com> wrote:
> >
> > > Hi Kuan-Po,
> > >
> > > The proposal to add the new
> remote.log.manager.follower.thread.pool.size
> > > config, LGTM.
> > > Thanks for making this change!
> > >
> > > --
> > > Kamal
> > >
> > > On Mon, May 12, 2025 at 10:19 PM KuanPo Tseng 
> > > wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > I’d like to discuss a KIP regarding introducing a new configuration,
> > > > remote.log.manager.follower.thread.pool.size
> > > >
> > > > Thank you!
> > > >
> > > > KIP link: https://cwiki.apache.org/confluence/x/xAlWFQ
> > > >
> > > > Best,
> > > > Kuan-Po Tseng
> > > >
> > >
> >
>

Re: [DISCUSS] KIP-1179: Introduce remote.log.manager.follower.thread.pool.size config

[Luke Chen]

Hi Kuan-Po,

Thanks for the explanation and KIP update.

I have no more questions.

Luke

On Wed, May 21, 2025 at 11:15 AM Kuan-Po Tseng  wrote:

> Hi Luke
>
> Thanks for your feedback!
>
> L1, L2: The logic for
> `RemoteLogManagerConfig#remoteLogManagerFollowerThreadPoolSize` is shown
> below.
> ```
> public int remoteLogManagerFollowerThreadPoolSize() {
> if
>
> (config.originals().containsKey(REMOTE_LOG_MANAGER_FOLLOWER_THREAD_POOL_SIZE_PROP))
> {
> return
> config.getInt(REMOTE_LOG_MANAGER_FOLLOWER_THREAD_POOL_SIZE_PROP);
> } else {
> return config.getInt(REMOTE_LOG_MANAGER_THREAD_POOL_SIZE_PROP);
> }
> }
> ```
> This method first checks whether the user has explicitly set
> remote.log.manager.follower.thread.pool.size.
> If not, it falls back to remote.log.manager.thread.pool.size.
> So remote.log.manager.follower.thread.pool.size always takes precedence,
> regardless of whether it's configured statically in the broker config file
> or dynamically at runtime.
>
> For example, if the user sets remote.log.manager.thread.pool.size=10 and
> later
> dynamically configures remote.log.manager.follower.thread.pool.size=8, the
> follower thread pool size will be 8.
>
> I’ll also update this example in the "Compatibility, Deprecation, and
> Migration Plan" section.
>
> Best,
> Kuan-Po
>
>
>
>
>
> On Tue, May 20, 2025 at 10:43 AM Luke Chen  wrote:
>
> > Hi Kuan-Po,
> >
> > Thanks for the KIP!
> >
> > Questions:
> > 1. If `remote.log.manager.thread.pool.size` is set and
> > `remote.log.manager.follower.thread.pool.size` is not set, we will still
> > honor the setting in `remote.log.manager.thread.pool.size`, right? We
> > should add in KIP to make it clear.
> >
> > 2. Suppose `remote.log.manager.thread.pool.size=10` and
> > `remote.log.manager.follower.thread.pool.size` is not set, could we do
> > dynamically config change to
> `remote.log.manager.follower.thread.pool.size`
> > config? The value of will be
> `remote.log.manager.follower.thread.pool.size`
> > 10 or default 2?
> >
> > Thank you.
> > Luke
> >
> >
> > On Tue, May 20, 2025 at 9:28 AM Kuan-Po Tseng 
> wrote:
> >
> > > Hello everyone,
> > >
> > > Just giving this thread a little nudge. If there’s no more feedback,
> I’ll
> > > kick off the vote tomorrow.
> > > Also, thanks to Kamal for reviewing this KIP!
> > >
> > > Best Regards,
> > > Kuan-Po
> > >
> > > On Mon, May 19, 2025 at 11:16 PM Kamal Chandraprakash <
> > > kamal.chandraprak...@gmail.com> wrote:
> > >
> > > > Hi Kuan-Po,
> > > >
> > > > The proposal to add the new
> > remote.log.manager.follower.thread.pool.size
> > > > config, LGTM.
> > > > Thanks for making this change!
> > > >
> > > > --
> > > > Kamal
> > > >
> > > > On Mon, May 12, 2025 at 10:19 PM KuanPo Tseng 
> > > > wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > I’d like to discuss a KIP regarding introducing a new
> configuration,
> > > > > remote.log.manager.follower.thread.pool.size
> > > > >
> > > > > Thank you!
> > > > >
> > > > > KIP link: https://cwiki.apache.org/confluence/x/xAlWFQ
> > > > >
> > > > > Best,
> > > > > Kuan-Po Tseng
> > > > >
> > > >
> > >
> >
>

[jira] [Resolved] (KAFKA-18783) Extend InvalidConfigurationException related exceptions

[Kaushik Raina (Jira)]

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

Kaushik Raina resolved KAFKA-18783.
---
Resolution: Fixed

> Extend InvalidConfigurationException related exceptions
> ---
>
> Key: KAFKA-18783
> URL: https://issues.apache.org/jira/browse/KAFKA-18783
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Kaushik Raina
>Assignee: Kaushik Raina
>Priority: Major
>




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

Re: Missing Response Formats in Kafka Protocol Guide

[Chia-Ping Tsai]

hi Andy

ziming comment is right. I will check your PR later

Best,
Chia-Ping

ziming deng  於 2025年5月21日 週三 上午10:22寫道：

> I don’t have experience generating content for kafka.apache.org , but
> according to the content of https://github.com/apache/kafka-site , I
> guess it will be regenerated the next time the kafka-site repository is
> updated, but I’m not sure about it.
>
> -
> Ziming
>
> > On May 21, 2025, at 9:17 AM, Andy Li  wrote:
> >
> > The PR was merged by Chia-Ping.
> >
> > Guys, do you know what's the next scheduled date when
> > https://kafka.apache.org/protocol.html will be updated? Thanks!
> >
> > - Andy
> >
> >
> > On Tue, 20 May 2025 at 11:44, Andy Li  wrote:
> >
> >> PR opened: https://github.com/apache/kafka/pull/19769 Thanks!
> >>
> >> - Andy
> >>
> >>
> >> On Tue, 20 May 2025 at 11:35, Ziming Deng 
> >> wrote:
> >>
> >>> Can you submit a PR to fix it? Thank you!
> >>>
>  On May 20, 2025, at 11:26, Andy Li  wrote:
> 
>  Hey Ziming,
> 
>  Thanks for pointing to org.apache.kafka.common.protocol.Protocal.main!
> 
>  It seem that this line should use `<=` instead `<`:
> 
>  Protocol.java <
> >>>
> https://github.com/apache/kafka/blob/cff10e654149ed2d4924235a15156d4bc0bf7b4a/clients/src/main/java/org/apache/kafka/common/protocol/Protocol.java#L211
> 
> 
> 
> 
>  - Andy
> 
> 
>  On Tue, 20 May 2025 at 10:38, Ziming Deng  >>> > wrote:
> > Hello Andi,
> > This page content is generated from
> >>> org.apache.kafka.common.protocol.Protocal.main , can you help to check
> it?
> >
> >> On May 20, 2025, at 09:13, Andy Li  >>> a...@codecrafters.io>> wrote:
> >>
> >> Hi Kafka Team,
> >>
> >> I noticed a couple of response formats missing from the Kafka
> >>> protocol guide
> >> :
> >>
> >> - *ApiVersions Response (Version: 4)* — Only versions 0–3 are
> >>> documented,
> >> though version 4 of the request is included.
> >>
> >> - *DescribeTopicPartitions Response* — Not listed at all.
> >>
> >> - *Fetch Response (Version: 17)* — Only versions 4–16 are
> documented,
> >> though version 17 of the request is included.
> >>
> >> Just wanted to flag in case this was unintentional. Thanks for all
> >>> the
> >> great work on Kafka!
> >>
> >> Best,
> >>
> >> Andy Li
> >
> >>>
> >>>
>
>

Re: [DISCUSS] KIP-646: Serializer API should support ByteBuffer

[TengYao Chi]

Hi everyone,

I want to bump this thread manually.
Thanks for your attention.

Best,
TengYao

TengYao Chi  於 2025年5月6日 週二 下午12:27寫道：

> Hello everyone,
>
> I want to start a discussion thread on KIP-646
> , which proposes enabling
> the Serializer API to support ByteBuffer.
>
> Please take a look and let me know what you think.
> I would appreciate any suggestions and feedback.
>
> Best regards,
> TengYao
>
>
>

Re: [VOTE] KIP-1135: Deprecated "org.apache.kafka.disallowed.login.modules"

[黃竣陽]

Thank for this KIP.

+1 (non-binding)

Best Regards,
Jiunn-Yang

> Luke Chen  於 2025年5月20日 上午10:25 寫道：
> 
> +1 (binding) from me.
> 
> Thanks for the KIP.
> Luke
> 
> On Mon, May 19, 2025 at 11:12 PM Chia-Ping Tsai  wrote:
> 
>> +1 (binding)
>> 
>> 龚宣璋  於 2025年5月14日 週三 下午7:29寫道：
>> 
>>> Hi Chia-Ping
>>> You are right.
>>> I don't think this should be optional. We should enforce the use of the
>>> allowlist
>>> 
>>> Chia-Ping Tsai  于2025年5月14日周三 13:07写道：
>>> 
 hi Xuan-Zhang
 
 (optional) we can deprecate `org.apache.kafka.disallowed.login.modules`
>>> and
 print warning message when users explicitly define it.
 
 
 This should not be optional, right?
 
 Best,
 Chia-Ping
 
 龚宣璋  於 2025年5月14日 週三 上午10:22寫道：
 
> Hi, kafka communityI would like to start a vote on KIP-1135:
>> Deprecated
> "org.apache.kafka.disallowed.login.modules"  <
> 
 
>>> 
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037077
> <
> 
 
>>> 
>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1146%3A+Anchored+punctuation
>>> 
> - Xuan-Zhang Gong
> 
 
>>> 
>> 

[VOTE] KIP-1153: Refactor Kafka Streams CloseOptions to Fluent API Style

[黃竣陽]

Hello all,

I would like to call a vote on KIP-1153: Refactor Kafka Streams CloseOptions to 
Fluent API Style

KIP:


Discussion thread:


Best Regards,
Jiunn-Yang

Re: [VOTE] KIP-1135: Deprecated "org.apache.kafka.disallowed.login.modules"

[Manikumar]

Thanks for this KIP.

+1 (binding)

On Tue, May 20, 2025 at 5:42 PM 黃竣陽  wrote:

> Thank for this KIP.
>
> +1 (non-binding)
>
> Best Regards,
> Jiunn-Yang
>
> > Luke Chen  於 2025年5月20日 上午10:25 寫道：
> >
> > +1 (binding) from me.
> >
> > Thanks for the KIP.
> > Luke
> >
> > On Mon, May 19, 2025 at 11:12 PM Chia-Ping Tsai 
> wrote:
> >
> >> +1 (binding)
> >>
> >> 龚宣璋  於 2025年5月14日 週三 下午7:29寫道：
> >>
> >>> Hi Chia-Ping
> >>> You are right.
> >>> I don't think this should be optional. We should enforce the use of the
> >>> allowlist
> >>>
> >>> Chia-Ping Tsai  于2025年5月14日周三 13:07写道：
> >>>
>  hi Xuan-Zhang
> 
>  (optional) we can deprecate
> `org.apache.kafka.disallowed.login.modules`
> >>> and
>  print warning message when users explicitly define it.
> 
> 
>  This should not be optional, right?
> 
>  Best,
>  Chia-Ping
> 
>  龚宣璋  於 2025年5月14日 週三 上午10:22寫道：
> 
> > Hi, kafka communityI would like to start a vote on KIP-1135:
> >> Deprecated
> > "org.apache.kafka.disallowed.login.modules"  <
> >
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=340037077
> > <
> >
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1146%3A+Anchored+punctuation
> >>>
> > - Xuan-Zhang Gong
> >
> 
> >>>
> >>
>
>

Re: [RESULTS] [VOTE] Release Kafka version 3.9.1

[Satya Bezawada]

Wondering why this release is not available on the official downloads page yet, 
https://kafka.apache.org/downloads
[http://apache-kafka.org/images/apache-kafka.png]
Apache Kafka
Apache Kafka: A Distributed Streaming Platform.
kafka.apache.org


From: TengYao Chi 
Sent: Sunday, May 18, 2025 12:05 PM
To: dev@kafka.apache.org ; kafka-clie...@googlegroups.com 
; us...@kafka.apache.org 

Subject: [RESULTS] [VOTE] Release Kafka version 3.9.1

This vote passes with 8 +1 votes (3 bindings) and no 0 or -1 votes.

+1 votes
PMC Members:
* Josep Prat
* Justine Olshan
* Mickael Maison

Committers:
N/A

Community:
* Paolo Patierno
* Kuan Po Tseng

* Jiunn-Yang Huang

* PoAn Yang

* Hong-Yi Chen

0 votes * No votes -1 votes * No votes Vote thread:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2F5q9337moctfl6y3rdpbwcldf9bm6o1ml&data=05%7C02%7C%7C7adbe8f966ed4c8cbca108dd96260ca6%7C84df9e7fe9f640afb435%7C1%7C0%7C638831812352614023%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=qHcqyxXWBu0Yf79M%2FIatvr3bhhEd9kbR4wtgOlz4hfw%3D&reserved=0
 I'll
continue with the release process and the release announcement will follow
in the next few days. TengYao Chi

[jira] [Created] (KAFKA-19319) Don't reset election timeout for prospective on transition to prospectiveVoted

[Alyssa Huang (Jira)]

Alyssa Huang created KAFKA-19319:


 Summary: Don't reset election timeout for prospective on 
transition to prospectiveVoted
 Key: KAFKA-19319
 URL: https://issues.apache.org/jira/browse/KAFKA-19319
 Project: Kafka
  Issue Type: Improvement
Reporter: Alyssa Huang


The original argument is that we reset the election timeout after a node grants 
a vote to another candidate to prevent the following scenario:

T1 - unattached A receives vote request from candidate B in epoch X
T2 - unattached A grants vote for candidate B in epoch X
T3 - unattached A's election timer expires, transitions to candidate with 
bumped epoch X + 1 and disrupts the chance of candidate B winning election in 
epoch X

As part of Pre-Vote, we copied this logic for when unattached/prospective 
grants a vote to a candidate - but we can see from the above example if node A 
was in unattached/prospective state instead, on expiry of the election timeout 
it would just transition to a state with the same epoch which is 
non-disruptive. 

We can remove resetting the election timeout (and fix corresponding tests) for 
both the unattachedAddVotedState and prospectiveAddVotedState methods.



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