KIP-1117: Support keystore with multiple alias entries

Hi Mickael, Based on review comment on PR https://github.com/apache/kafka/pull/17560, we have submitted the KIP : https://cwiki.apache.org/confluence/display/KAFKA/KIP-1117%3A+Support+keystore+with+multiple+alias+entries Could you please review this? Please let us know for any additional details

[jira] [Resolved] (KAFKA-18881) Document the ConsumerRecord as non-thread safe

[ https://issues.apache.org/jira/browse/KAFKA-18881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-18881. Fix Version/s: 4.1.0 Resolution: Fixed > Document the ConsumerRecord as non-thread

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

deliberately. For this case, what was the reason that the 3-prior-release rule was ignored? -Matthias On 3/1/25 11:29 PM, Chia-Ping Tsai wrote: 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 ma

[jira] [Resolved] (KAFKA-17793) Improve kcontroller robustness against long delays

[ https://issues.apache.org/jira/browse/KAFKA-17793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-17793. Fix Version/s: 4.0.0 Resolution: Fixed > Improve kcontroller robustness against lon

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

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

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

[ https://issues.apache.org/jira/browse/KAFKA-18907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-18907. Resolution: Fixed > add suitable error message when the appended value is too larger > ---

[jira] [Created] (KAFKA-18909) Move DynamicThreadPool to server module

Chia-Ping Tsai created KAFKA-18909: -- Summary: Move DynamicThreadPool to server module Key: KAFKA-18909 URL: https://issues.apache.org/jira/browse/KAFKA-18909 Project: Kafka Issue Type: Sub-t

[jira] [Created] (KAFKA-18910) Move kafka.utils.json to tool module

Chia-Ping Tsai created KAFKA-18910: -- Summary: Move kafka.utils.json to tool module Key: KAFKA-18910 URL: https://issues.apache.org/jira/browse/KAFKA-18910 Project: Kafka Issue Type: Sub-task

[jira] [Resolved] (KAFKA-18748) Run new integration tests separately in PRs

[ https://issues.apache.org/jira/browse/KAFKA-18748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chia-Ping Tsai resolved KAFKA-18748. Fix Version/s: 4.1.0 Resolution: Fixed > Run new integration tests separately in PR

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

hi Matthias, I apologize, I used the wrong word in my previous response. The PR "deliberately" removed the public API, but it was an "oversight" that we weren't aware of the "3 prior releases" rule.[0] To simplify the upgrade path, I suggest reverting this change in 4.x and creating a ticket t

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

Hmm, where is this 3 release rule documented? I don't recall it being agreed as a project wide rule before. Do you have a reference? Ismael On Sat, Mar 1, 2025, 2:32 PM Matthias J. Sax wrote: > Don't have a strong opinion about the Connect case. > > I guess the question is: why was it removed?

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

> For this case, what was the reason that the 3-prior-release rule was ignored? According to KIP-970 ( https://cwiki.apache.org/confluence/display/KAFKA/KIP-970%3A+Deprecate+and+remove+Connect%27s+redundant+task+configurations+endpoint), it seems the main reason to avoid "a bit of a maintenance bu