[jira] [Created] (KAFKA-18906) Upgrade to Junit 5.13 and apply ParameterizedClass

Chia-Ping Tsai created KAFKA-18906: -- Summary: Upgrade to Junit 5.13 and apply ParameterizedClass Key: KAFKA-18906 URL: https://issues.apache.org/jira/browse/KAFKA-18906 Project: Kafka Issue

[jira] [Created] (KAFKA-18908) the size of appended value can't be larger than Short.MAX_VALUE

Chia-Ping Tsai created KAFKA-18908: -- Summary: the size of appended value can't be larger than Short.MAX_VALUE Key: KAFKA-18908 URL: https://issues.apache.org/jira/browse/KAFKA-18908 Project: Kafka

[jira] [Resolved] (KAFKA-17981) add Integration test for ConfigCommand to add config `key=[val1,val2]`

[ https://issues.apache.org/jira/browse/KAFKA-17981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17981. Fix Version/s: 4.1.0 Resolution: Fixed > add Integration test for ConfigCommand to

Re: [DISCUSS] KIP-1124: Providing a clear Kafka Client upgrade path

hi > If this Connect case is the only one that deviates from that rule, I would recommended reverting it. But if there are many more cases, we may need to look into them in more detail. I briefly checked the commit history, and this is the only one that needs to be highlighted. Fortunately, it is

Re: [DISCUSS] KIP-1124: Providing a clear Kafka Client upgrade path

Don't have a strong opinion about the Connect case. I guess the question is: why was it removed? Oversight (ie, accidentally too early) or deliberately? Also, what is the impact if we keep the API and revert the removal? IMHO, the 3-releases-rule can have exceptions, if there are good reason

[jira] [Created] (KAFKA-18905) Avoid out of order sequence errors from multiple in-flight batches

Sean Quah created KAFKA-18905: - Summary: Avoid out of order sequence errors from multiple in-flight batches Key: KAFKA-18905 URL: https://issues.apache.org/jira/browse/KAFKA-18905 Project: Kafka

Re: [DISCUSS] KIP-1133: AK Documentation and Website in Markdown

Hi, I am totally in favor to make this happen, and I was disappointed each time in the past, when it was proposed but we did not do it. Given that it is a huge effort, I am wondering if it would be sufficient to just to this change for 4.0 release though, and not translate any older versio

[jira] [Resolved] (KAFKA-18880) Remove kafka.cluster.Broker and BrokerEndPointNotAvailableException

[ https://issues.apache.org/jira/browse/KAFKA-18880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-18880. Fix Version/s: 4.1.0 Resolution: Fixed > Remove kafka.cluster.Broker and BrokerEndP

[jira] [Resolved] (KAFKA-18868) add the "default value" explanation to the docs of num.replica.alter.log.dirs.threads

[ https://issues.apache.org/jira/browse/KAFKA-18868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-18868. Resolution: Fixed trunk: [https://github.com/apache/kafka/commit/2ccc73783e30bde27aebb2a2

Re: [DISCUSS] KIP-1124: Providing a clear Kafka Client upgrade path

Hi Chia-Ping, Is this Connect removal the only one that did not meet the stated requirement? We do indeed aim not to remove APIs deprecated within the last 12 months before the next major release, but I'm not sure how strictly this is followed (since it's not enforced). If this Connect case is t

[jira] [Resolved] (KAFKA-17039) KIP-919 supports for `unregisterBroker`

[ https://issues.apache.org/jira/browse/KAFKA-17039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17039. Fix Version/s: 4.1.0 Resolution: Fixed > KIP-919 supports for `unregisterBroker` >

Re: [DISCUSS] KIP-1124: Providing a clear Kafka Client upgrade path

One more thing, 3.7 was released in Feb 2024 and hence it will be more than 12 months by the time 4.0 is released. Technically, it would be ok to remove APIs deprecated in 3.7. Ismael On Sat, Mar 1, 2025, 8:34 AM Ismael Juma wrote: > Hi Chia-Ping, > > Is this Connect removal the only one that d

[jira] [Created] (KAFKA-18907) add suitable error message when the appended value is too larger

Chia-Ping Tsai created KAFKA-18907: -- Summary: add suitable error message when the appended value is too larger Key: KAFKA-18907 URL: https://issues.apache.org/jira/browse/KAFKA-18907 Project: Kafka

Re: [DISCUSS] KIP-1136: Make ConsumerGroupMetadata an interface

Hi Kirk Many thanks for very good questions! KT1. I don't think that internal implementation should totally prevent of passing alternative implementation, but for sure we need to log warning when producer receives different than default implementaion. I think that checking internally is the class