Re: [DISCUSS] KIP-1148: Remove log.cleaner.enable configuration

[TengYao Chi]

Hi Chia-Ping
Nice catch!
I have updated the KIP.

Best,
TengYao

Chia-Ping Tsai  於 2025年5月11日 週日 下午4:34寫道：

> hi Teng
>
> Sorry for raising issue on the accepted KIP.
>
> In 5.0 the log cleaner should be always enabled and so the config
> log.cleaner.threads should NOT accept min value of zero, right?
>
> Hence, could you please add the behavior changes “the min value should be
> 1” to this KIP?
>
> Best,
> Chia-Ping
>
> On 2025/03/25 04:10:34 TengYao Chi wrote:
> > Hello everyone,
> >
> > I want to start a discussion thread on KIP-1148
> > , which proposes removing
> the
> > `log.cleaner.enable` configuration.
> >
> > Please take a look and let me know what you think.
> > I would appreciate any suggestions and feedback.
> >
> > Best regards,
> > TengYao
> >
>

[jira] [Created] (KAFKA-19267) the min version used by ListOffsetsRequest should be 1 rather than 0

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-19267:
--

 Summary: the min version used by ListOffsetsRequest should be 1 
rather than 0
 Key: KAFKA-19267
 URL: https://issues.apache.org/jira/browse/KAFKA-19267
 Project: Kafka
  Issue Type: Improvement
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai


in the protocol, `ListOffsetsRequest` v0 is unsupported - but in the code base 
we still set the  oldestAllowedVersion to 0. 



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

Re: [DISCUSS] KIP-1148: Remove log.cleaner.enable configuration

[Chia-Ping Tsai]

hi TengYao

please sync the update to the vote thread. thanks

Best,
Chia-Ping

TengYao Chi  於 2025年5月12日 週一 上午12:07寫道：

> Hi Chia-Ping
> Nice catch!
> I have updated the KIP.
>
> Best,
> TengYao
>
> Chia-Ping Tsai  於 2025年5月11日 週日 下午4:34寫道：
>
> > hi Teng
> >
> > Sorry for raising issue on the accepted KIP.
> >
> > In 5.0 the log cleaner should be always enabled and so the config
> > log.cleaner.threads should NOT accept min value of zero, right?
> >
> > Hence, could you please add the behavior changes “the min value should be
> > 1” to this KIP?
> >
> > Best,
> > Chia-Ping
> >
> > On 2025/03/25 04:10:34 TengYao Chi wrote:
> > > Hello everyone,
> > >
> > > I want to start a discussion thread on KIP-1148
> > > , which proposes removing
> > the
> > > `log.cleaner.enable` configuration.
> > >
> > > Please take a look and let me know what you think.
> > > I would appreciate any suggestions and feedback.
> > >
> > > Best regards,
> > > TengYao
> > >
> >
>

Jenkins build is still unstable: Kafka » Kafka PowerPC Daily » test-powerpc #295

[Apache Jenkins Server]

See 

Re: [VOTE] KIP-1148: Remove log.cleaner.enable configuration

[TengYao Chi]

Hi everyone,

Chia-Ping has raised a concern for another configuration,
`log.cleaner.threads`, which is highly related to `log.cleaner.enable`
Given that the user cannot close the log cleaner, `log.cleaner.threads`
should also have a lower bound of 1.
I have updated the KIP.
Please take a look.

Best,
TengYao.

TengYao Chi  於 2025年4月14日 週一 上午11:28寫道：

> Hello everyone,
>
> The vote is now closed, and the KIP has been accepted with 3 binding +1s
> from
> Chia-Ping, Andrew, and Lianet
>
> As well as 3 non-binding +1 from
> Kuan Po, Jiunn-Yang, and PoAn.
>
> Thank you all for your participation!
>
> Sincerely,
> TengYao
>
> Lianet M.  於 2025年4月10日 週四 下午8:48寫道：
>
>> Thanks for the KIP!
>>
>> +1 (binding)
>>
>> Lianet
>>
>> On Thu, Apr 10, 2025 at 7:17 AM PoAn Yang  wrote:
>>
>> > Thanks for the KIP.
>> >
>> > +1 (non-binding)
>> >
>> > PoAn
>> >
>> > > On Apr 10, 2025, at 6:55 PM, 黃竣陽  wrote:
>> > >
>> > > Thanks for the KIP.
>> > >
>> > > +1 (non-binding),
>> > >
>> > >> Andrew Schofield  於 2025年4月10日
>> > 下午4:30 寫道：
>> > >>
>> > >> Thanks for the KIP.
>> > >>
>> > >> +1 (binding)
>> > >>
>> > >> Andrew
>> > >>
>> > >> From: Kuan Po Tseng 
>> > >> Date: Thursday, 10 April 2025 at 09:05
>> > >> To: dev@kafka.apache.org 
>> > >> Subject: Re: [VOTE] KIP-1148: Remove log.cleaner.enable configuration
>> > >>
>> > >> +1 (non-binding), thanks for the KIP.
>> > >>
>> > >> On 2025/04/10 07:51:53 TengYao Chi wrote:
>> > >>> Hello everyone,
>> > >>>
>> > >>> I would like to call a vote on KIP-1148
>> > >>> <
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcwiki.apache.org%2Fconfluence%2Fx%2FXAyWF&data=05%7C02%7C%7Ca95de0e322b14c71981208dd78066a6c%7C84df9e7fe9f640afb435%7C1%7C0%7C638798691134154001%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mg8M%2BJIBvr0eB4oPlrON32XTS8APRL05LZG%2FPPgXaYc%3D&reserved=0
>> > >.
>> > >>>
>> > >>> Here <
>> >
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread%2Fdjgd2gzl1n2qlqw48mcxnr8h9sob32yz&data=05%7C02%7C%7Ca95de0e322b14c71981208dd78066a6c%7C84df9e7fe9f640afb435%7C1%7C0%7C638798691134177534%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PMYeZ68%2BFkcSm66KXaYTz0zD4Kyjp4lhE%2FTKekBveDY%3D&reserved=0
>> > > is
>> > >>> the discussion thread.
>> > >>>
>> > >>>
>> > >>> Best Regards,
>> > >>> TengYao
>> > >>>
>> > >
>> >
>> >
>>
>

Re: [DISCUSS] KIP-1161: cleanup.policy shouldn't be empty

[Chia-Ping Tsai]

hi Luke

We can print warnings for empty cleanup.policy in 4.x and in 5.0 we throw 
exception directly to make it fail fast

Jiunn:   WDYT?

Best,
Chia-Ping

> Luke Chen  於 2025年5月12日 上午10:52 寫道：
> 
> Hi Jiunn-Yang,
> 
> Thanks for the KIP.
> 
> Comments:
> 1. "it is acceptable because an empty cleanup.policy is considered invalid
> in Kafka. Therefore, this trade-off is justified."
> Could you explain more about this? Why is this trade-off justified?
> If we think the empty cleanup.policy is invalid in kafka, why do we provide
> an additional "none" option to users in this KIP?
> FYI, there are indeed use cases that need to keep all history data without
> a cleanup policy.
> 
> 2. Following (1), I agree we should fail fast for empty
> "group.coordinator.rebalance.protocols" and "process.roles" configs since
> they are invalid.
> But about "cleanup.policy", I don't see a persuasive reason why we should
> break backward compatibility to change it.
> "This provides a clear and direct way to configure Kafka to retain all log
> segments without any automatic cleanup."
> This is the motivation we mentioned in the KIP, but to me, backward
> compatibility is much more important than "a clear and direct way to config
> kafka".
> Do we really have to change the "cleanup.policy" config?
> 
> Thanks.
> Luke
> 
> 
>> On Wed, May 7, 2025 at 2:17 AM Jun Rao  wrote:
>> 
>> Hi, Jiunn-Yang,
>> 
>> Thanks for the updated KIP. It looks good to me.
>> 
>> Jun
>> 
>>> On Tue, May 6, 2025 at 4:58 AM 黃竣陽  wrote:
>>> 
>>> Hi Jun, chia
>>> 
>>> Thanks for all the comments. They have all been addressed in the updated
>>> KIP.
>>> 
>>> I've removed all deprecated-related sections. Additionally, an exception
>>> will now be thrown if a
>>> developer passes an empty validStrings list to the inNonEmpty method.
>>> 
>>> Best Regards,
>>> Jiunn-Yang
>>> 
 Chia-Ping Tsai  於 2025年5月6日 凌晨12:46 寫道：
 
 hi Jiunn-Yang
 
 The `inNonEmpty` is used to prevent users pass empty config, so should
>> it
 be non-empty too?
 
 For example, `inNonEmpty()` should throw exception directly.
 
 Best,
 Chia-Ping
 
 Jun Rao  於 2025年5月6日 週二 上午12:28寫道：
 
> Hi, Jiunn-Yang,
> 
> Thanks for the reply. There are still references to the deprecated
>>> method.
> 
> "stop relying on the deprecated methods"
> "Finally, the deprecated method will be removed in Kafka 5.0"
> 
> Thanks,
> 
> Jun
> 
> On Sat, May 3, 2025 at 7:42 AM 黃竣陽  wrote:
> 
>> Hi Jun, chia,
>> 
>> Thanks for all the comments. They have all been addressed in the
>>> updated
>> KIP.
>> 
>> Best Regards,
>> Jiunn-Yang
>> 
>>> Chia-Ping Tsai  於 2025年5月3日 凌晨2:03 寫道：
>>> 
>>> hi Jiunn-Yang
>>> 
>>> in the "Compatibility, Deprecation, and Migration Plan", could you
>> add
>>> description to remind readers that "clean.policy=" should be
>> replaced
> by
>>> "clean.policy=none" if they do want to disable delete and compact.
>>> 
>>> Best,
>>> Chia-Ping
>>> 
>>> Jun Rao  於 2025年5月3日 週六 上午1:55寫道：
>>> 
 Hi, Jiunn-Yang,
 
 It's fine not to deprecate ValidList#in for now. Could you update
>> the
>> KIP
 completely? There are still references to deprecation.
 
 Thanks,
 
 Jun
 
 On Fri, May 2, 2025 at 4:59 AM 黃竣陽  wrote:
 
> Hi Jun,
> 
> I don’t think we should deprecate the ValidList#in method, as
>> there
> may
 be
> future scenarios where we want
> to allow list configs to be empty. It’s useful to have both
>> methods:
> in
> (which allows empty lists)
> and inNonEmpty (which enforces non-empty lists).
> 
>> Just a minor comment. It would be useful to document that during
 upgrade,
>> if cleanup.policy is empty, the broker will fail to start.
> 
> I’ve updated the KIP accordingly.
> 
> Best Regards,
> Jiunn-Yang
> 
>> Jun Rao  於 2025年5月2日 凌晨12:50 寫道：
>> 
>> Hi, Jiunn-Yang,
>> 
>> Thanks for the reply. Sounds good.
>> 
>> Just a minor comment. It would be useful to document that during
 upgrade,
>> if cleanup.policy is empty, the broker will fail to start.
>> 
>> Jun
>> 
>> On Thu, May 1, 2025 at 8:40 AM 黃竣陽  wrote:
>> 
>>> Hello Jun,
>>> 
>>> Since ValidList is a public API, we need to maintain backward
>>> compatibility. Therefore, the isEmptyAllowed flag is necessary.
>>> We can update the signature of isNonEmpty() to remove the
>> boolean
>>> parameter.
>>> 
>>> Best Regards,
>>> Jiunn-Yang
>>> 
 Jun Rao  於 2025年5月1日 凌晨4:17 寫道：
 
 Hi, Jiunn-Yang,

[jira] [Created] (KAFKA-19266) Eliminate flakiness in test SharePartitionTest.testAcquisitionLockTimeoutForBatchesPostStartOffsetMovement

[Abhinav Dixit (Jira)]

Abhinav Dixit created KAFKA-19266:
-

 Summary: Eliminate flakiness in test 
SharePartitionTest.testAcquisitionLockTimeoutForBatchesPostStartOffsetMovement
 Key: KAFKA-19266
 URL: https://issues.apache.org/jira/browse/KAFKA-19266
 Project: Kafka
  Issue Type: Sub-task
Reporter: Abhinav Dixit


There seems to be flakiness in test 
SharePartitionTest.testAcquisitionLockTimeoutForBatchesPostStartOffsetMovement  
[https://develocity.apache.org/scans/tests?search.rootProjectNames=kafka&search.timeZoneId=Asia%2FCalcutta&tests.container=kafka.server.share.SharePartitionTest&tests.test=testAcquisitionLockTimeoutForBatchesPostStartOffsetMovement()]
 which is unrelated to acquisition lock timeout, but more related to 
initialization of share partition



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

[jira] [Resolved] (KAFKA-18695) Remove quorum=kraft and kip932 from all integration tests

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-18695.

Fix Version/s: 4.1.0
   Resolution: Fixed

> Remove quorum=kraft and kip932 from all integration tests
> -
>
> Key: KAFKA-18695
> URL: https://issues.apache.org/jira/browse/KAFKA-18695
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Chia-Ping Tsai
>Assignee: Ming-Yen Chung
>Priority: Major
> Fix For: 4.1.0
>
>
> all integration tests are using kraft mode so we don't need to use 
> `quorum=kraft`



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

[jira] [Resolved] (KAFKA-19264) Remove fallback for thread pool sizes in RemoteLogManagerConfig

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-19264.

Fix Version/s: 4.1.0
   Resolution: Fixed

> Remove fallback for thread pool sizes in RemoteLogManagerConfig
> ---
>
> Key: KAFKA-19264
> URL: https://issues.apache.org/jira/browse/KAFKA-19264
> Project: Kafka
>  Issue Type: Task
>  Components: Tiered-Storage
>Reporter: Kuan Po Tseng
>Assignee: Kuan Po Tseng
>Priority: Minor
> Fix For: 4.1.0
>
>
> The fallback mechanism was first introduced in 
> [KIP-950|https://cwiki.apache.org/confluence/x/joqzDw]. According to the 
> proposal, if no thread values are set for 
> {{remote.log.manager.copier.thread.pool.size}} and 
> {{{}remote.log.manager.expiration.thread.pool.size{}}}, these two configs 
> would default to using the value of 
> {{{}remote.log.manager.thread.pool.size{}}}.
> As quoted from the KIP:
> {quote}If no thread values are set for the two new configurations presented 
> later on in the document we will default to using the same number of threads 
> in each pool as detailed by remote.log.manager.thread.pool.size.
> {quote}
> This fallback behavior was implemented in 
> [https://github.com/apache/kafka/commit/84ab3b9a5c4930f5ae047df088e38c456c7cde54].
> However, this approach was abandoned in 
> [KIP-1030|https://cwiki.apache.org/confluence/x/FAqpEQ], where the default 
> values for {{copier}} and {{expiration}} thread pool sizes were changed from 
> {{-1}} to {{{}10{}}}. The related commit can be found in 
> [https://github.com/apache/kafka/commit/3b1bd3812e48d488e4b6b53a9085d6552e8adf02].
> Additionally, both {{remote.log.manager.copier.thread.pool.size}} and 
> {{remote.log.manager.expiration.thread.pool.size}} now include a 
> configuration validator that enforces a minimum value of {{{}1{}}}. This 
> means the fallback mechanism should be removed from 
> [RemoteLogManagerConfig.java|https://github.com/apache/kafka/blob/trunk/storage/src/main/java/org/apache/kafka/server/log/remote/storage/RemoteLogManagerConfig.java]
>  to align with the new defaults and validation.
> In short, RemoteLogManagerConfig should apply the following changes:
> {code:java}
>  public int remoteLogManagerCopierThreadPoolSize() {
> -int size = 
> config.getInt(REMOTE_LOG_MANAGER_COPIER_THREAD_POOL_SIZE_PROP);
> -return size == -1 ? remoteLogManagerThreadPoolSize() : size;
> +return 
> config.getInt(REMOTE_LOG_MANAGER_COPIER_THREAD_POOL_SIZE_PROP);
>  }
>  public int remoteLogManagerExpirationThreadPoolSize() {
> -int size = 
> config.getInt(REMOTE_LOG_MANAGER_EXPIRATION_THREAD_POOL_SIZE_PROP);
> -return size == -1 ? remoteLogManagerThreadPoolSize() : size;
> +return 
> config.getInt(REMOTE_LOG_MANAGER_EXPIRATION_THREAD_POOL_SIZE_PROP);
>  }{code}



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

Re: [DISCUSS] KIP-1161: cleanup.policy shouldn't be empty

[Luke Chen]

Hi Jiunn-Yang,

Thanks for the KIP.

Comments:
1. "it is acceptable because an empty cleanup.policy is considered invalid
in Kafka. Therefore, this trade-off is justified."
Could you explain more about this? Why is this trade-off justified?
If we think the empty cleanup.policy is invalid in kafka, why do we provide
an additional "none" option to users in this KIP?
FYI, there are indeed use cases that need to keep all history data without
a cleanup policy.

2. Following (1), I agree we should fail fast for empty
"group.coordinator.rebalance.protocols" and "process.roles" configs since
they are invalid.
But about "cleanup.policy", I don't see a persuasive reason why we should
break backward compatibility to change it.
"This provides a clear and direct way to configure Kafka to retain all log
segments without any automatic cleanup."
This is the motivation we mentioned in the KIP, but to me, backward
compatibility is much more important than "a clear and direct way to config
kafka".
Do we really have to change the "cleanup.policy" config?

Thanks.
Luke


On Wed, May 7, 2025 at 2:17 AM Jun Rao  wrote:

> Hi, Jiunn-Yang,
>
> Thanks for the updated KIP. It looks good to me.
>
> Jun
>
> On Tue, May 6, 2025 at 4:58 AM 黃竣陽  wrote:
>
> > Hi Jun, chia
> >
> > Thanks for all the comments. They have all been addressed in the updated
> > KIP.
> >
> > I've removed all deprecated-related sections. Additionally, an exception
> > will now be thrown if a
> > developer passes an empty validStrings list to the inNonEmpty method.
> >
> > Best Regards,
> > Jiunn-Yang
> >
> > > Chia-Ping Tsai  於 2025年5月6日 凌晨12:46 寫道：
> > >
> > > hi Jiunn-Yang
> > >
> > > The `inNonEmpty` is used to prevent users pass empty config, so should
> it
> > > be non-empty too?
> > >
> > > For example, `inNonEmpty()` should throw exception directly.
> > >
> > > Best,
> > > Chia-Ping
> > >
> > > Jun Rao  於 2025年5月6日 週二 上午12:28寫道：
> > >
> > >> Hi, Jiunn-Yang,
> > >>
> > >> Thanks for the reply. There are still references to the deprecated
> > method.
> > >>
> > >> "stop relying on the deprecated methods"
> > >> "Finally, the deprecated method will be removed in Kafka 5.0"
> > >>
> > >> Thanks,
> > >>
> > >> Jun
> > >>
> > >> On Sat, May 3, 2025 at 7:42 AM 黃竣陽  wrote:
> > >>
> > >>> Hi Jun, chia,
> > >>>
> > >>> Thanks for all the comments. They have all been addressed in the
> > updated
> > >>> KIP.
> > >>>
> > >>> Best Regards,
> > >>> Jiunn-Yang
> > >>>
> >  Chia-Ping Tsai  於 2025年5月3日 凌晨2:03 寫道：
> > 
> >  hi Jiunn-Yang
> > 
> >  in the "Compatibility, Deprecation, and Migration Plan", could you
> add
> >  description to remind readers that "clean.policy=" should be
> replaced
> > >> by
> >  "clean.policy=none" if they do want to disable delete and compact.
> > 
> >  Best,
> >  Chia-Ping
> > 
> >  Jun Rao  於 2025年5月3日 週六 上午1:55寫道：
> > 
> > > Hi, Jiunn-Yang,
> > >
> > > It's fine not to deprecate ValidList#in for now. Could you update
> the
> > >>> KIP
> > > completely? There are still references to deprecation.
> > >
> > > Thanks,
> > >
> > > Jun
> > >
> > > On Fri, May 2, 2025 at 4:59 AM 黃竣陽  wrote:
> > >
> > >> Hi Jun,
> > >>
> > >> I don’t think we should deprecate the ValidList#in method, as
> there
> > >> may
> > > be
> > >> future scenarios where we want
> > >> to allow list configs to be empty. It’s useful to have both
> methods:
> > >> in
> > >> (which allows empty lists)
> > >> and inNonEmpty (which enforces non-empty lists).
> > >>
> > >>> Just a minor comment. It would be useful to document that during
> > > upgrade,
> > >>> if cleanup.policy is empty, the broker will fail to start.
> > >>
> > >> I’ve updated the KIP accordingly.
> > >>
> > >> Best Regards,
> > >> Jiunn-Yang
> > >>
> > >>> Jun Rao  於 2025年5月2日 凌晨12:50 寫道：
> > >>>
> > >>> Hi, Jiunn-Yang,
> > >>>
> > >>> Thanks for the reply. Sounds good.
> > >>>
> > >>> Just a minor comment. It would be useful to document that during
> > > upgrade,
> > >>> if cleanup.policy is empty, the broker will fail to start.
> > >>>
> > >>> Jun
> > >>>
> > >>> On Thu, May 1, 2025 at 8:40 AM 黃竣陽  wrote:
> > >>>
> >  Hello Jun,
> > 
> >  Since ValidList is a public API, we need to maintain backward
> >  compatibility. Therefore, the isEmptyAllowed flag is necessary.
> >  We can update the signature of isNonEmpty() to remove the
> boolean
> >  parameter.
> > 
> >  Best Regards,
> >  Jiunn-Yang
> > 
> > > Jun Rao  於 2025年5月1日 凌晨4:17 寫道：
> > >
> > > Hi, Jiunn-Yang,
> > >
> > > Thanks for the reply.
> > >
> > > Do we really need isEmptyAllowed? It's awkward since the method
> > >> name
> > > is
> > > inNonEmpty. Also, it's not clear when it's set t

[jira] [Created] (KAFKA-19264) Remove fallback for thread pool sizes in RemoteLogManagerConfig

[Kuan Po Tseng (Jira)]

Kuan Po Tseng created KAFKA-19264:
-

 Summary: Remove fallback for thread pool sizes in 
RemoteLogManagerConfig
 Key: KAFKA-19264
 URL: https://issues.apache.org/jira/browse/KAFKA-19264
 Project: Kafka
  Issue Type: Task
  Components: Tiered-Storage
Reporter: Kuan Po Tseng
Assignee: Kuan Po Tseng


The fallback mechanism was first introduced in 
[KIP-950|https://cwiki.apache.org/confluence/x/joqzDw]. According to the 
proposal, if no thread values are set for 
{{remote.log.manager.copier.thread.pool.size}} and 
{{{}remote.log.manager.expiration.thread.pool.size{}}}, these two configs would 
default to using the value of {{{}remote.log.manager.thread.pool.size{}}}.

As quoted from the KIP:
{quote}If no thread values are set for the two new configurations presented 
later on in the document we will default to using the same number of threads in 
each pool as detailed by remote.log.manager.thread.pool.size.
{quote}
This fallback behavior was implemented in 
[https://github.com/apache/kafka/commit/84ab3b9a5c4930f5ae047df088e38c456c7cde54].

However, this approach was abandoned in 
[KIP-1030|https://cwiki.apache.org/confluence/x/FAqpEQ], where the default 
values for {{copier}} and {{expiration}} thread pool sizes were changed from 
{{-1}} to {{{}10{}}}. The related commit can be found in 
[https://github.com/apache/kafka/commit/3b1bd3812e48d488e4b6b53a9085d6552e8adf02].

Additionally, both {{remote.log.manager.copier.thread.pool.size}} and 
{{remote.log.manager.expiration.thread.pool.size}} now include a configuration 
validator that enforces a minimum value of {{{}1{}}}. This means the fallback 
mechanism should be removed from 
[{{RemoteLogManagerConfig.java}}|https://issues.apache.org/jira/issues/RemoteLogManagerConfig.java]
 to align with the new defaults and validation.

In short, RemoteLogManagerConfig should apply the following changes:
{code:java}
 public int remoteLogManagerCopierThreadPoolSize() {
-int size = 
config.getInt(REMOTE_LOG_MANAGER_COPIER_THREAD_POOL_SIZE_PROP);
-return size == -1 ? remoteLogManagerThreadPoolSize() : size;
+return config.getInt(REMOTE_LOG_MANAGER_COPIER_THREAD_POOL_SIZE_PROP);
 }

 public int remoteLogManagerExpirationThreadPoolSize() {
-int size = 
config.getInt(REMOTE_LOG_MANAGER_EXPIRATION_THREAD_POOL_SIZE_PROP);
-return size == -1 ? remoteLogManagerThreadPoolSize() : size;
+return 
config.getInt(REMOTE_LOG_MANAGER_EXPIRATION_THREAD_POOL_SIZE_PROP);
 }{code}



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

[jira] [Resolved] (KAFKA-19139) Plugin#wrapInstance should use LinkedHashMap instead of Map

[TaiJuWu (Jira)]

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

TaiJuWu resolved KAFKA-19139.
-
Resolution: Fixed

> Plugin#wrapInstance should use LinkedHashMap instead of Map 
> 
>
> Key: KAFKA-19139
> URL: https://issues.apache.org/jira/browse/KAFKA-19139
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: 黃竣陽
>Assignee: 黃竣陽
>Priority: Major
>
> See discussion: 
> https://github.com/apache/kafka/pull/19050#discussion_r2041133707



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

Re: [DISCUSS] KIP-1100: Consider renaming org.apache.kafka.server:type=AssignmentsManager

[Chia-Ping Tsai]

hi Jiunn-Yang

Could you please file a ticket to address Ismael comment? That can be addressed 
even though this KIP is still in progress.

Best,
Chia-Ping


> 黃竣陽  於 2025年5月11日 下午1:42 寫道：
> 
> Jiunn-Yang

[jira] [Created] (KAFKA-19262) Add a test to verify all metrics naming pattern

[Jira]

黃竣陽 created KAFKA-19262:
---

 Summary: Add a test to verify all metrics naming pattern 
 Key: KAFKA-19262
 URL: https://issues.apache.org/jira/browse/KAFKA-19262
 Project: Kafka
  Issue Type: Improvement
Reporter: 黃竣陽
Assignee: 黃竣陽


We should add an integration test for KafkaYammerMetrics to ensure all metric 
names conform to the expected naming convention.
see disscussion: 
[https://lists.apache.org/thread/5wx7b724v9yhqytonbvc3vbyf5fsbsrp]
 



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

Re: [DISCUSS] KIP-1100: Consider renaming org.apache.kafka.server:type=AssignmentsManager

[黃竣陽]

Hi chia,

File a Jira to trace it https://issues.apache.org/jira/browse/KAFKA-19262

Best Regards,
Jiunn-Yang

> 黃竣陽  於 2025年5月11日 下午1:41 寫道：
> 
> Hi Ismael, chia,
> 
> Thanks for all the feedback. I’ve updated the KIP.
> 
>> 2. Given that we regressed in two different instances (that we found so
>> far), this indicates a test gap combined with a brittle coding pattern. We
>> should consider how to fix this going forward. It's not specific to the KIP
>> itself (which is focused on the user facing aspects), but important.
>> Perhaps we can add a test that iterates through all metrics and verifies
>> the naming pattern.
> 
> I agree, We should add an integration test for KafkaYammerMetrics 
> to ensure all metric names conform to the expected naming convention.
> 
> Best Regards,
> Jiunn-Yang
> 
>> Ismael Juma  於 2025年5月11日 凌晨1:44 寫道：
>> 
>> Hi,
>> 
>> Thanks for the KIP. A couple of comments:
>> 1. Nit: KIPs should not "consider" things, they propose specific and well
>> defined changes. Given that, please update the title to match the proposal.
>> 2. Given that we regressed in two different instances (that we found so
>> far), this indicates a test gap combined with a brittle coding pattern. We
>> should consider how to fix this going forward. It's not specific to the KIP
>> itself (which is focused on the user facing aspects), but important.
>> Perhaps we can add a test that iterates through all metrics and verifies
>> the naming pattern.
>> 
>> Ismael
>> 
>> On Sun, Oct 27, 2024 at 9:23 AM 黃竣陽  wrote:
>> 
>>> Hello everyone,
>>> 
>>> I would like to start a discussion about KIP-1100
>>> <
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1100%3A+Consider+renaming+org.apache.kafka.server%3Atype%3DAssignmentsManager
 
>>> In this KIP, we plan to update the `AssignmentsManager` metric name from
>>> `org.apache.kafka.server:type=AssignmentsManager` to
>>> `kafka.server:type=AssignmentsManager`.
>>> 
>>> 
>>> Any feedback and suggestions for the KIP are welcome in this email thread.
>>> 
>>> Thank you!
>>> Best regards,
>>> Jiunn-Yang
> 

[jira] [Created] (KAFKA-19265) Use snapshotting of remote log metedata topic that is used when a broker is restarted.

[Satish Duggana (Jira)]

Satish Duggana created KAFKA-19265:
--

 Summary: Use snapshotting of remote log metedata topic that is 
used when a broker is restarted.
 Key: KAFKA-19265
 URL: https://issues.apache.org/jira/browse/KAFKA-19265
 Project: Kafka
  Issue Type: Improvement
  Components: core
Reporter: Satish Duggana
Assignee: Kamal Chandraprakash
 Fix For: 4.1.0






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

Re: [DISCUSS] KIP-1148: Remove log.cleaner.enable configuration

[Chia-Ping Tsai]

hi Teng

Sorry for raising issue on the accepted KIP. 

In 5.0 the log cleaner should be always enabled and so the config 
log.cleaner.threads should NOT accept min value of zero, right?

Hence, could you please add the behavior changes “the min value should be 1” to 
this KIP?

Best,
Chia-Ping

On 2025/03/25 04:10:34 TengYao Chi wrote:
> Hello everyone,
> 
> I want to start a discussion thread on KIP-1148
> , which proposes removing the
> `log.cleaner.enable` configuration.
> 
> Please take a look and let me know what you think.
> I would appreciate any suggestions and feedback.
> 
> Best regards,
> TengYao
> 

Re: [DISCUSS] KIP-1148: Remove log.cleaner.enable configuration

[Chia-Ping Tsai]

hi Teng

Sorry for raising issue on the accepted KIP. 

In 5.0 the log cleaner should be always enabled and so the config 
log.cleaner.threads should NOT accept min value of zero, right?

Hence, could you please add the behavior changes “the min value should be 1” to 
this KIP?

Best,
Chia-Ping

On 2025/03/25 04:10:34 TengYao Chi wrote:
> Hello everyone,
> 
> I want to start a discussion thread on KIP-1148
> , which proposes removing the
> `log.cleaner.enable` configuration.
> 
> Please take a look and let me know what you think.
> I would appreciate any suggestions and feedback.
> 
> Best regards,
> TengYao
> 

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

[龚宣璋]

Hi everyone,


Just checking in — does anyone have any further thoughts or comments on
this discussion thread?


If there are no objections, I’ll go ahead and send out the voting
notification tomorrow.


Best regards,

Xuan-Zhang Gong

[jira] [Created] (KAFKA-19263) The docs of delete.topic.enable used by Admin#deletetopics is out-of-date

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-19263:
--

 Summary: The docs of delete.topic.enable used by 
Admin#deletetopics  is out-of-date
 Key: KAFKA-19263
 URL: https://issues.apache.org/jira/browse/KAFKA-19263
 Project: Kafka
  Issue Type: Improvement
Reporter: Chia-Ping Tsai


* If delete.topic.enable is false on the brokers, deleteTopics will mark
 * the topics for deletion, but not actually delete them. The futures will
 * return successfully in this case.

It is not true as the server return exception now.

if (!config.deleteTopicEnable) {
  if (apiVersion < 3) {
throw new InvalidRequestException("Topic deletion is disabled.")
  } else {
throw new TopicDeletionDisabledException()
  }
}




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