[jira] [Created] (KAFKA-18119) Service loading loads incorrect plugin version.

[Snehashis Pal (Jira)]

Snehashis Pal created KAFKA-18119:
-

 Summary: Service loading loads incorrect plugin version.
 Key: KAFKA-18119
 URL: https://issues.apache.org/jira/browse/KAFKA-18119
 Project: Kafka
  Issue Type: Bug
  Components: connect
Affects Versions: 3.8.1, 3.9.0, 3.7.1, 3.8.0, 3.6.2, 3.6.1, 3.7.0, 3.6.0
Reporter: Snehashis Pal


Kafka connect seems to be loading incorrect version of connect plugins (such as 
connectors) if run in SERVICE_LOAD mode. If the worker is started with only 
service loading enabled, it does not seem to be loading the latest version of a 
plugin available in its plugins path. Rather it always seems to be defaulting 
to the plugin version provided in the classpath. 

I observed this when I placed an updated json-converter in the plugins path and 
a connector instantiated, still defaulted to using the one provided in the 
connect (Kafka) distribution. It does not happen when the older 
reflections-based plugin scanner is used. This can be reproduced by following 
the same process, noted down below
 * Set {*}plugin.discovery{*}=SERVICE_LOAD
 * Install a newer version of json-converter 
({*}org.apache.kafka.connect.json.JsonConverter{*}) than the one provided in 
the distribution. Usually, the bundled version is the same as the current Kafka 
distribution. 
 * Start a connector with either *key.converter* or *value.converter* set to 
the json converter. Without this in the config the latest version is loaded.

It might be hard to judge which version of the converter is loaded. For testing 
it might be good to build a new json converter with some log lines depicting 
the version in use. Another way would be run connect in debug mode and add some 
breakpoints in the startTask method in Worker where the converters are 
initialised.



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

Re: [DISCUSS] KIP-1111: Enforcing Explicit Naming for Kafka Streams Internal Topics

[Lucas Brutschy]

Hi all,

Thanks for the KIP! Super useful.

No new comments, let me just voice my opinion on the suggestions being made.

A1: When I read `require.auto.generated.topic.names`, it sounds like
explicit naming is not allowed if the config is true. This is not what
we are doing here. So to avoid the negative, I'd use
`require.explicit.topic.names`, default false.

BC+1: I think `invariant` is quite indirect, because it depends on
what changes are being made for the naming to change or not. Also,
it's not only about changelog topics but also repartition topics, so
`persistance` seems misleading as well. I agree, IQ can benefit, but
it seems that it is more of a side effect of the feature?

BC+2: Big +1 on this.

Cheers,
Lucas




On Tue, Nov 26, 2024 at 9:37 PM Sebastien Viale
 wrote:
>
> Thanks Bruno for your comments:
>
> A1 .
> BC+1.
> I let other people give their advice, and each of them makes sense.
>
> BC+2.
> I believe you're right. I think I can manage to check whether names are set 
> for repartition or changelog topics across different DSL operators in 
> KStreamImpl. The complexity arises because repartition topic names can depend 
> on the operator, such as selectKey before a join.
> If I detect unnamed topics, I could introduce a property like 
> unNamedInternalTopics in  InternalStreamBuilder to maintain a list of unnamed 
> topics that I can check when topology is built. This approach would allow me 
> to focus not only on sequence numbers but also on ensuring explicit topic 
> naming for improved stability. I hope this is what you imagine.
> Let me know if you need further refinements!
>
> Sébastien,
>
>
>
> 
> De : Bruno Cadonna 
> Envoyé : mardi 26 novembre 2024 19:12
> À : dev@kafka.apache.org 
> Objet : [EXT] Re: [DISCUSS] KIP-: Enforcing Explicit Naming for Kafka 
> Streams Internal Topics
>
> Warning External sender Do not click on any links or open any attachments 
> unless you trust the sender and know the content is safe.
>
> Hi,
>
> Thanks for the KIP!
>
> A1.
> I find the "auto.generated.topic.names" part a bit misleading, because
> actually the topic names are always auto-generated no matter if the
> processors and state stores are explicitly named or not.
>
> which leads me to
>
> BC+1.
> IMO this is not only about topic names, explicitly naming state stores
> would also benefit existing IQ queries. So the config should not
> necessarily be only focused on internal topics.
> Maybe a config name like invariant.persistence.naming or
> ensure.invariant.persistence.naming or
> enabled.invariant.persistence.naming. I am not too happy with the names
> but I hope you get the idea.
>
> BC+2.
> Can we not keep track of explicit naming within the DSL instead of
> relying on the 10-digit sequence number?
>
> Best,
> Bruno
>
> This email was screened for spam and malicious content but exercise caution 
> anyway.
>
>
>
> On 22.11.24 22:04, Sebastien Viale wrote:
> > hi,
> > A1. Personally, I prefer the suggestion: require.auto.generated.topic.names.
> > If everyone agrees, I will update the KIP accordingly.
> > MJS-1. Sophie, I reviewed the ticket and the sub-tasks, and everything 
> > seems clear to me. I must say that I sometimes felt confused with the 
> > constructors, but now everything is much clearer. Based on my experience 
> > and discussions with my teammates, I believe this is a good opportunity to 
> > simplify and clarify the implementation.
> > The question is whether this should be part of a separate KIP.
> > I don’t see any issue with integrating it into the current one, but if 
> > necessary, I’m happy to volunteer to open a new KIP.
> > In both cases, would it be okay for you if I validate it with you before 
> > publishing?
> > cheers !
> >
> >
> >
> > 
> > De : Sophie Blee-Goldman 
> > Envoyé : vendredi 22 novembre 2024 01:33
> > À : dev@kafka.apache.org 
> > Objet : [EXT] Re: [DISCUSS] KIP-: Enforcing Explicit Naming for Kafka 
> > Streams Internal Topics
> >
> > Warning External sender Do not click on any links or open any attachments 
> > unless you trust the sender and know the content is safe.
> >
> > First off, thanks for the KIP! I think this is a great idea as it's super
> > easy to miss naming one thing and end up with a topology that isn't
> > upgradeable.
> >
> > A1. I actually had the same reaction as Almog to the name, I feel it's
> > slightly clearer as a positive instead of a negative, though I think the
> > rest of it is fine -- what about "require.auto.generated.topic.names"
> > instead?
> >
> > MJS-1. While I can see the advantage of having this stuff be
> > programmatically configured, I personally would prefer to keep this and
> > other topology-related configurations part of StreamsConfig. For one thing,
> > I think they would be much more discoverable as true configs. For another,
> > this still wouldn't solve the problem for configs that need to be passed in
> > up front, that is, 

Re: [VOTE] KIP-1099: Extend kafka-consumer-groups command line tool to support new consumer group

[Lucas Brutschy]

Hi PoAn,

a minor follow-up question. The isClassic boolean in the Admin API,
seems to use a boxed type `Boolean` instead of an unboxed boolean. It
seems we could use the unboxed type here.

Cheers,
Lucas

On Tue, Nov 26, 2024 at 1:55 AM PoAn Yang  wrote:
>
> Hi everyone,
>
> Thanks for your voting.
>
> The KIP passes with 4 +1 (binding) votes from Chia-Ping Tsai,
> David Jacot, Lianet M., Jeff Kim and 1 +1 (non-binding) from Andrew Schofield.
>
> Thank you.
>
> Best,
> PoAn
>
> > On Nov 26, 2024, at 12:39 AM, Jeff Kim  wrote:
> >
> > Thanks!
> >
> > +1 (binding)
> >
> > Jeff
> >
> > On 2024/11/25 15:46:04 "Lianet M." wrote:
> >> Thanks for the KIP and updates PoAn!
> >>
> >> +1 (binding)
> >>
> >> Lianet
> >>
> >> On Mon, Nov 25, 2024, 10:43 a.m. Andrew Schofield <
> >> andrew_schofield_j...@outlook.com> wrote:
> >>
> >>> +1 (non-binding)
> >>>
> >>> Thanks,
> >>> Andrew
> >>>
> >>> 
> >>> From: David Jacot 
> >>> Sent: 25 November 2024 15:38
> >>> To: dev@kafka.apache.org 
> >>> Subject: Re: [VOTE] KIP-1099: Extend kafka-consumer-groups command line
> >>> tool to support new consumer group
> >>>
> >>> +1 (binding)
> >>>
> >>> In gmail, the discuss and the vote threads got merged somehow.
> >>>
> >>> On Wed, Nov 20, 2024 at 4:47 AM Chia-Ping Tsai 
> >>> wrote:
> >>>
>  +1 (binding)
> 
>  On 2024/11/18 14:52:22 PoAn Yang wrote:
> > Hi All,
> >
> > I would like to start vote on KIP-1099:
> >
> 
> >>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group
> >
> > Discussion thread:
> > https://lists.apache.org/thread/lo64123wm3kjmjsx72xg67wvjx9nykk8
> >
> > Thanks,
> > PoAn
> 
> >>>
> >>
>

Re: [VOTE] KIP-1030: Change constraints and default values for various configurations

[Federico Valeri]

+1 non binding.

Thanks

On Thu, Nov 28, 2024 at 3:16 AM Kamal Chandraprakash
 wrote:
>
> Hi Divij,
>
> +1 (Binding). Thanks for the KIP!
>
> Kamal
>
> On Thu, Nov 28, 2024, 05:37 Luke Chen  wrote:
>
> > Hi Divij,
> >
> > +1 (binding) from me.
> > Thanks for the KIP!
> >
> > Luke
> >
> > On Thu, Nov 28, 2024 at 12:21 AM Divij Vaidya 
> > wrote:
> >
> > > Corresponding discussion thread:
> > > https://lists.apache.org/thread/kxw9kxn49kt30kwckzwp8vq3k7kmrz9m
> > >
> > > Please vote if you agree with proceeding ahead with the proposal. Votes
> > > from all community members are cordially invited.
> > >
> > > --
> > > Divij Vaidya
> > >
> >

Re: [VOTE] KIP-1099: Extend kafka-consumer-groups command line tool to support new consumer group

[PoAn Yang]

Hi Lucas,

Thanks for the reminder. Yes, we can use an unboxed boolean.
Update the KIP.

Thanks,
PoAn

> On Nov 28, 2024, at 8:23 PM, Lucas Brutschy  
> wrote:
> 
> Hi PoAn,
> 
> a minor follow-up question. The isClassic boolean in the Admin API,
> seems to use a boxed type `Boolean` instead of an unboxed boolean. It
> seems we could use the unboxed type here.
> 
> Cheers,
> Lucas
> 
> On Tue, Nov 26, 2024 at 1:55 AM PoAn Yang  wrote:
>> 
>> Hi everyone,
>> 
>> Thanks for your voting.
>> 
>> The KIP passes with 4 +1 (binding) votes from Chia-Ping Tsai,
>> David Jacot, Lianet M., Jeff Kim and 1 +1 (non-binding) from Andrew 
>> Schofield.
>> 
>> Thank you.
>> 
>> Best,
>> PoAn
>> 
>>> On Nov 26, 2024, at 12:39 AM, Jeff Kim  wrote:
>>> 
>>> Thanks!
>>> 
>>> +1 (binding)
>>> 
>>> Jeff
>>> 
>>> On 2024/11/25 15:46:04 "Lianet M." wrote:
 Thanks for the KIP and updates PoAn!
 
 +1 (binding)
 
 Lianet
 
 On Mon, Nov 25, 2024, 10:43 a.m. Andrew Schofield <
 andrew_schofield_j...@outlook.com> wrote:
 
> +1 (non-binding)
> 
> Thanks,
> Andrew
> 
> 
> From: David Jacot 
> Sent: 25 November 2024 15:38
> To: dev@kafka.apache.org 
> Subject: Re: [VOTE] KIP-1099: Extend kafka-consumer-groups command line
> tool to support new consumer group
> 
> +1 (binding)
> 
> In gmail, the discuss and the vote threads got merged somehow.
> 
> On Wed, Nov 20, 2024 at 4:47 AM Chia-Ping Tsai 
> wrote:
> 
>> +1 (binding)
>> 
>> On 2024/11/18 14:52:22 PoAn Yang wrote:
>>> Hi All,
>>> 
>>> I would like to start vote on KIP-1099:
>>> 
>> 
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1099%3A+Extend+kafka-consumer-groups+command+line+tool+to+support+new+consumer+group
>>> 
>>> Discussion thread:
>>> https://lists.apache.org/thread/lo64123wm3kjmjsx72xg67wvjx9nykk8
>>> 
>>> Thanks,
>>> PoAn
>> 
> 
 
>> 

[jira] [Created] (KAFKA-18115) Issue loading big files for performance testing

[Manoj Mathivanan (Jira)]

Manoj Mathivanan created KAFKA-18115:


 Summary: Issue loading big files for performance testing
 Key: KAFKA-18115
 URL: https://issues.apache.org/jira/browse/KAFKA-18115
 Project: Kafka
  Issue Type: Bug
  Components: tools
Reporter: Manoj Mathivanan
Assignee: Manoj Mathivanan


When performing producer performance tests, we can specify a payload using the 
{{*--payloadFile*}} parameter. This file is utilized during the 
load/performance testing process. However, if the file is large, it may result 
in the following error:
{code:java}
Exception in thread "main" java.lang.NegativeArraySizeException: -1040351534
at java.base/java.lang.String.(String.java:568) {code}



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

[jira] [Resolved] (KAFKA-18110) Fail Test: PlaintextAdminIntegrationTest#testDeleteConsumerGroupOffsets

[Jira]

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

黃竣陽 resolved KAFKA-18110.
-
Resolution: Won't Fix

> Fail Test: PlaintextAdminIntegrationTest#testDeleteConsumerGroupOffsets
> ---
>
> Key: KAFKA-18110
> URL: https://issues.apache.org/jira/browse/KAFKA-18110
> Project: Kafka
>  Issue Type: Bug
>Reporter: 黃竣陽
>Assignee: 黃竣陽
>Priority: Major
>
> In [PR]([https://github.com/apache/kafka/pull/16899#issuecomment-2504803872)] 
> we find a test fail
> ```
>  
> {{Expected an exception of type 
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException; got type 
> org.apache.kafka.common.errors.GroupIdNotFoundException
> Expected :true
> Actual   :false
> 
> org.opentest4j.AssertionFailedError: Expected an exception of type 
> org.apache.kafka.common.errors.UnknownTopicOrPartitionException; got type 
> org.apache.kafka.common.errors.GroupIdNotFoundException ==> expected:  
> but was: 
>   at 
> org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>   at 
> org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>   at org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
>   at org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
>   at org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:214)}}
> ```



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

[jira] [Created] (KAFKA-18116) Admin LeaveGroup fails for static consumer group member

[Lianet Magrans (Jira)]

Lianet Magrans created KAFKA-18116:
--

 Summary: Admin LeaveGroup fails for static consumer group member 
 Key: KAFKA-18116
 URL: https://issues.apache.org/jira/browse/KAFKA-18116
 Project: Kafka
  Issue Type: Bug
  Components: group-coordinator
Reporter: Lianet Magrans
Assignee: David Jacot
 Fix For: 4.0.0


A LeaveGroup request sent by an admin client returns UNKNOWN_MEMBER_ID for a 
static consumer group member, due to this validation:

https://github.com/apache/kafka/blob/d334f60944fa51622f0035039fa36d6d98405c59/group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupMetadataManager.java#L6132

This does not allow admin removal of static consumer members. The behaviour is 
covered in PlaintextAdminIntegrationTest, currently passing for the classic 
consumer but failing for the new async consumer on this assertion.

https://github.com/apache/kafka/blob/d334f60944fa51622f0035039fa36d6d98405c59/core/src/test/scala/integration/kafka/api/PlaintextAdminIntegrationTest.scala#L2031
 



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

[jira] [Resolved] (KAFKA-17997) Remove deprecated config log.message.timestamp.difference.max.ms

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-17997.

Resolution: Fixed

> Remove deprecated config log.message.timestamp.difference.max.ms
> 
>
> Key: KAFKA-17997
> URL: https://issues.apache.org/jira/browse/KAFKA-17997
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Divij Vaidya
>Assignee: Hyunsang Han
>Priority: Major
>  Labels: breaking, newbie
> Fix For: 4.0.0
>
>
> _[log.message.timestamp.difference.max.ms|https://kafka.apache.org/documentation.html#brokerconfigs_log.message.timestamp.difference.max.ms]_
>  was deprecated as part of KIP 937. We need to remove it from 4.0.
> The exit criteria for this Jira should be:
> 1. Remove the configuration from the code and associated tests.
> 2. Update documentation at 
> [https://github.com/apache/kafka/blob/trunk/docs/upgrade.html#L25] to add the 
> removed configuration
> [1] 
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-937%3A+Improve+Message+Timestamp+Validation]
>  



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

Re: [VOTE] KIP-1030: Change constraints and default values for various configurations

[Satish Duggana]

+1 (binding)

~Satish.

On Thu, 28 Nov 2024 at 15:46, Federico Valeri  wrote:
>
> +1 non binding.
>
> Thanks
>
> On Thu, Nov 28, 2024 at 3:16 AM Kamal Chandraprakash
>  wrote:
> >
> > Hi Divij,
> >
> > +1 (Binding). Thanks for the KIP!
> >
> > Kamal
> >
> > On Thu, Nov 28, 2024, 05:37 Luke Chen  wrote:
> >
> > > Hi Divij,
> > >
> > > +1 (binding) from me.
> > > Thanks for the KIP!
> > >
> > > Luke
> > >
> > > On Thu, Nov 28, 2024 at 12:21 AM Divij Vaidya 
> > > wrote:
> > >
> > > > Corresponding discussion thread:
> > > > https://lists.apache.org/thread/kxw9kxn49kt30kwckzwp8vq3k7kmrz9m
> > > >
> > > > Please vote if you agree with proceeding ahead with the proposal. Votes
> > > > from all community members are cordially invited.
> > > >
> > > > --
> > > > Divij Vaidya
> > > >
> > >

Re: [DISCUSS] KIP-1030: Change constraints and default values for various configurations

[Divij Vaidya]

Agreed about the validation tool. I have already added it in the
"compatibility" section of the KIP. Will create a separate JIRA for it as
soon as KIP is approved.

--
Divij Vaidya



On Thu, Nov 28, 2024 at 5:35 AM Satish Duggana 
wrote:

> Hi Kamal, Thanks for updating the KIP with the offline discussion we
> had, especially on remotelog.manager.* thread pools with the new
> behaviour.
>
> Hi Divij, We should target having a validation tool in 4.0 so that
> users can run it before they run their upgrade and take necessary
> actions on it. I am fine with updating the KIP with those details
> later when PRs are raised.
>
> Thanks,
> Satish.
>
> On Thu, 28 Nov 2024 at 00:31, Divij Vaidya 
> wrote:
> >
> > Yes, Kamal, we will fix the tests that rely on low values of segment.ms
> as
> > part of the KIP implementation.
> >
> > --
> > Divij Vaidya
> >
> >
> >
> > On Wed, Nov 27, 2024 at 7:40 PM Jun Rao 
> wrote:
> >
> > > Hi, Kamal,
> > >
> > > Thanks for the explanation. This change sounds good to me then.
> > >
> > > Jun
> > >
> > > On Wed, Nov 27, 2024 at 10:31 AM Kamal Chandraprakash <
> > > kamal.chandraprak...@gmail.com> wrote:
> > >
> > > > Hi Jun,
> > > >
> > > > Thanks for the review! I've made the addendum to this KIP about the
> > > remote
> > > > storage configs:
> > > >
> > > > > 13. Why are the defaults for
> remote.log.manager.copier.thread.pool.size
> > > > and
> > > > remote.log.manager.thread.pool.size different?
> > > >
> > > > We have 3 thread pools in remote log manager:
> > > >
> > > > a. remote.log.manager.thread.pool.size: handles the RLMFollowerTask
> > > > <
> > > >
> > >
> https://sourcegraph.com/github.com/apache/kafka/-/blob/core/src/main/java/kafka/log/remote/RemoteLogManager.java?L1454
> > > > >
> > > > to read the highest-uploaded remote offset for follower partitions
> > > > b. remote.log.manager.copier.thread.pool.size: handles the
> RLMCopyTask
> > > > <
> > > >
> > >
> https://sourcegraph.com/github.com/apache/kafka/-/blob/core/src/main/java/kafka/log/remote/RemoteLogManager.java?L830
> > > > >
> > > > to copy the segments to remote storage
> > > > c. remote.log.manager.expiration.thread.pool.size: handles the
> > > > RLMExpirationTask
> > > > <
> > > >
> > >
> https://sourcegraph.com/github.com/apache/kafka/-/blob/core/src/main/java/kafka/log/remote/RemoteLogManager.java?L1095
> > > > >
> > > > to delete the expired remote segments.
> > > >
> > > > The plan was to deprecate the remote.log.manager.thread.pool.size
> > > > thread-pool after KIP-950 but it was not done
> > > > and used for the follower partition tasks. Compared to
> copier/expiration
> > > > tasks, the follower tasks are light-weight
> > > > so proposing to reduce that thread-pool size to 2.
> > > >
> > > > --
> > > > Kamal
> > > >
> > > > On Wed, Nov 27, 2024 at 11:48 PM Kamal Chandraprakash <
> > > > kamal.chandraprak...@gmail.com> wrote:
> > > >
> > > > > Hi Divij,
> > > > >
> > > > > I also share the same concern as Greg pointed out for
> segment.bytes /
> > > > > segment.index.bytes.
> > > > > All the tiered storage tests
> > > > > <
> > > >
> > >
> https://sourcegraph.com/github.com/apache/kafka/-/blob/storage/src/test/java/org/apache/kafka/tiered/storage/utils/TieredStorageTestUtils.java?L174
> > > > >
> > > > > might start to fail with the new defaults. I'm fine with the
> proposal
> > > > > provided we plan to fix those tests as part of this KIP.
> > > > >
> > > > > --
> > > > > Kamal
> > > > >
> > > > >
> > > > > On Wed, Nov 27, 2024 at 9:55 PM Divij Vaidya <
> divijvaidy...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hello everyone
> > > > >>
> > > > >> Since, I believe I have addressed all the concerns that were
> raised
> > > > here,
> > > > >> I
> > > > >> have started a vote thread for this KIP at
> > > > >> https://lists.apache.org/thread/39dmfkd7ktb0oo44yqrkndcn4kcqt5hc
> > > > >>
> > > > >> Please participate in the vote.
> > > > >>
> > > > >> --
> > > > >> Divij Vaidya
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Nov 27, 2024 at 12:33 PM Divij Vaidya <
> > > divijvaidy...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >> > Thanks for the feedback folks.
> > > > >> >
> > > > >> > *Jun*
> > > > >> >
> > > > >> > 10. Fixed it. It now says 2 as the new default for recovery
> threads.
> > > > >> >
> > > > >> > 11. I have added a sentence that we will apply the defaults for
> both
> > > > >> > broker level and equivalent topic level configs. I have further
> > > added
> > > > >> both
> > > > >> > the broker level and the topic level config to the table. For
> > > example,
> > > > >> you
> > > > >> > may notice (message.timestamp.after.max.ms /
> > > > >> > log.message.timestamp.after.max.ms). Furthermore, the
> constraints
> > > > will
> > > > >> > apply (similar to constraints today) when validating dynamically
> > > > changed
> > > > >> > configuration and also when validating static configuration
> (such as
> > > > >> > server.properties). Please let me know if I have missed
> anyth

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

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-18117) Support topic IDs in consumer SubscriptionState

[Lianet Magrans (Jira)]

Lianet Magrans created KAFKA-18117:
--

 Summary: Support topic IDs in consumer SubscriptionState
 Key: KAFKA-18117
 URL: https://issues.apache.org/jira/browse/KAFKA-18117
 Project: Kafka
  Issue Type: Bug
  Components: consumer
Reporter: Lianet Magrans
Assignee: Lianet Magrans


Include support for topicIds in subscription state to properly align with the 
new protocol assignments that contain topic IDs only (no name). This will allow 
the consumer to request metadata for assigned topic IDs only (not all topics). 



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

[jira] [Created] (KAFKA-18118) Fix the incorrect soft link of results/latest

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-18118:
--

 Summary: Fix the incorrect soft link of results/latest
 Key: KAFKA-18118
 URL: https://issues.apache.org/jira/browse/KAFKA-18118
 Project: Kafka
  Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Chia-Ping Tsai


chia7712@fedora:~/project/kafka$ ls -la results
總用量 12
drwxr-xr-x.  3 chia7712 chia7712 4096 11月 29 02:52 .
drwxr-xr-x. 44 chia7712 chia7712 4096 11月 29 02:51 ..
drwxr-xr-x.  3 chia7712 chia7712 4096 11月 29 02:52 2024-11-28--001
lrwxrwxrwx.  1 chia7712 chia7712   38 11月 29 02:52 latest -> 
/opt/kafka-dev/results/2024-11-28–001

`latest` is referenced to container path



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

[jira] [Resolved] (KAFKA-17820) Remove Utils.mkMap

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-17820.

Resolution: Won't Fix

kafka is still using null value so the helper method is still useful.

> Remove Utils.mkMap
> --
>
> Key: KAFKA-17820
> URL: https://issues.apache.org/jira/browse/KAFKA-17820
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Ming-Yen Chung
>Priority: Major
>




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

[jira] [Resolved] (KAFKA-17757) cleanup code case under JDK 11

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-17757.

Fix Version/s: 4.0.0
   Resolution: Fixed

> cleanup code case under JDK 11
> --
>
> Key: KAFKA-17757
> URL: https://issues.apache.org/jira/browse/KAFKA-17757
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Chia-Ping Tsai
>Assignee: Chia-Ping Tsai
>Priority: Major
> Fix For: 4.0.0
>
>
> We can leverage Java 11 features instead of relying on many small utility 
> functions.



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

[jira] [Resolved] (KAFKA-17758) Remove Utils.mkEntry

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-17758.

Resolution: Won't Fix

kafka is still using null value so the helper method is still useful.

> Remove Utils.mkEntry
> 
>
> Key: KAFKA-17758
> URL: https://issues.apache.org/jira/browse/KAFKA-17758
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Chia-Ping Tsai
>Assignee: Ming-Yen Chung
>Priority: Major
>
> They can be replaced by Map.entry and Map.ofEntries



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

[jira] [Resolved] (KAFKA-17979) Change [pytest] to [tool:pytest] in setup.cfg file

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-17979.

Fix Version/s: 4.0.0
   Resolution: Fixed

> Change [pytest] to [tool:pytest] in setup.cfg file
> --
>
> Key: KAFKA-17979
> URL: https://issues.apache.org/jira/browse/KAFKA-17979
> Project: Kafka
>  Issue Type: Test
>Reporter: PoAn Yang
>Assignee: PoAn Yang
>Priority: Minor
> Fix For: 4.0.0
>
>
> The [pytest] is deprecated. We have to change it to [tool:pytest].
>  Ref: https://github.com/pytest-dev/pytest/pull/1813



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

[jira] [Resolved] (KAFKA-14126) Convert remaining DynamicBrokerReconfigurationTest tests to KRaft

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-14126.

Resolution: Duplicate

see https://github.com/apache/kafka/pull/17905

> Convert remaining DynamicBrokerReconfigurationTest tests to KRaft
> -
>
> Key: KAFKA-14126
> URL: https://issues.apache.org/jira/browse/KAFKA-14126
> Project: Kafka
>  Issue Type: Test
>Reporter: David Arthur
>Assignee: David Arthur
>Priority: Major
>
> After the initial conversion in https://github.com/apache/kafka/pull/12455, 
> three tests still need to be converted. 
> * testKeyStoreAlter
> * testTrustStoreAlter
> * testThreadPoolResize



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

[jira] [Resolved] (KAFKA-15706) KRaft support in DynamicBrokerReconfigurationTest

[Chia-Ping Tsai (Jira)]

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

Chia-Ping Tsai resolved KAFKA-15706.

Resolution: Duplicate

see https://github.com/apache/kafka/pull/17905

> KRaft support in DynamicBrokerReconfigurationTest
> -
>
> Key: KAFKA-15706
> URL: https://issues.apache.org/jira/browse/KAFKA-15706
> Project: Kafka
>  Issue Type: Task
>  Components: core
>Reporter: Sameer Tejani
>Assignee: CJ Hillbrand
>Priority: Minor
>  Labels: kraft, kraft-test, newbie
>
> The following tests in DynamicBrokerReconfigurationTest in 
> core/src/test/scala/integration/kafka/server/DynamicBrokerReconfigurationTest.scala
>  need to be updated to support KRaft
> 621 : def testDefaultTopicConfig(): Unit = {
> 734 : def testUncleanLeaderElectionEnable(): Unit = {
> 795 : def testThreadPoolResize(): Unit = {
> 934 : def testMetricsReporterUpdate(): Unit = {
> 1022 : def testAdvertisedListenerUpdate(): Unit = {
> 1093 : def testAddRemoveSslListener(): Unit = {
> 1138 : def testAddRemoveSaslListeners(): Unit = {
> Scanned 1993 lines. Found 7 KRaft tests out of 14 tests



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