Bill Bejeck comments

Results 71 comments of


                                            Bill Bejeck

KAFKA-17609:[1/4] Changes needed to convert system tests to use KRaft and remove ZK

@mjsax all comments addressed

KAFKA-17609:[1/4] Changes needed to convert system tests to use KRaft and remove ZK

I kicked off a new branch builder for `streams_application_upgrade_test` and I'll post the link here when it completes.

KAFKA-17609:[1/4] Changes needed to convert system tests to use KRaft and remove ZK

[System test results](https://semaphore.ci.confluent.io/jobs/ce66d1c2-c5ad-453a-93d2-6577229db201/summary?report_id=0356f43b-c807-318c-b61e-09e8fdd4e976&suite_id=94b22e6d-3d1f-39cc-a647-051d783a5e26) 29 passed, 3 failed - I'll look into the failures.

KAFKA-17609:[1/4] Changes needed to convert system tests to use KRaft and remove ZK

[Link to all passing tests.](https://semaphore.ci.confluent.io/jobs/77ee30bb-55ae-4b7f-bda9-551af378e84a/summary?report_id=0356f43b-c807-318c-b61e-09e8fdd4e976) ![zk_to_kraft_migration_pr_1_results](https://github.com/user-attachments/assets/e949ee0e-4ed2-4eed-816f-e16afab76a4c)

KAFKA-17609:[1/4] Changes needed to convert system tests to use KRaft and remove ZK

Merged #17275 into trunk

KAFKA-18185: remove internal.leave.group.on.close config

@frankvicky I'm going to make a pass regarding [this comment ](https://github.com/apache/kafka/pull/19400#issuecomment-3242118581) from @lucasbru - ~I want to confirm if we are changing the default behavior, which is something I don't...

KAFKA-18185: remove internal.leave.group.on.close config

Merged #19400 into trunk

KAFKA-18193 Refactor Kafka Streams CloseOptions to Fluent API Style

@m1a2st can you rebase to fix the merge conflicts? Thanks Apologies for the delay in the reviewing we'll get this in soon.

KAFKA-18193 Refactor Kafka Streams CloseOptions to Fluent API Style

Merged #19955 into trunk

MINOR: Bytes lexicographic comparator could use compiler builtin

@stevenschlansker nice improvement! In addition to the suggestion from @squah-confluent , could also add a JMH benchmark for this in the `jmh-benchmarks` module? Not strictly necessary, but it's always good...