[jira] [Created] (KAFKA-17844) Add tests and fix to complete share fetch request on exception from manager

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-17844:
-

 Summary: Add tests and fix to complete share fetch request on 
exception from manager
 Key: KAFKA-17844
 URL: https://issues.apache.org/jira/browse/KAFKA-17844
 Project: Kafka
  Issue Type: Sub-task
Reporter: Apoorv Mittal
Assignee: Apoorv Mittal






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

Re: [DISCUSS] KIP-1098: Reverse Checkpointing in MirrorMaker

[Dániel Urbán]

Hi Mickael,
Good point, I renamed the KIP and this thread:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-1098%3A+Reverse+Checkpointing+in+MirrorMaker
Thank you,
Daniel

Mickael Maison  ezt írta (időpont: 2024. okt.
21., H, 15:22):

> Hi Daniel,
>
> I've not had time to take a close look at the KIP but my initial
> feedback would be to adjust the name to make it clear it's about
> MirrorMaker.
> The word "checkpoint" has several meanings in Kafka and from the
> current KIP name it's not clear if it's about KRaft, Streams or
> Connect.
>
> Thanks,
> Mickael
>
> On Mon, Oct 21, 2024 at 2:55 PM Dániel Urbán 
> wrote:
> >
> > Hi Viktor,
> >
> > Thank you for the comments!
> >
> > SVV1: I think the feature has some performance implications. If the
> reverse
> > checkpointing is enabled, task startup will be possibly slower, since it
> > will need to consume from a second offset-syncs topic; and it will also
> use
> > more memory, to keep the second offset-sync history. Additionally, it is
> > also possible to have an offset-syncs topic present without an actual,
> > opposite flow being active - I think only users can tell if the reverse
> > checkpointing should be active, and they should be the one opting in for
> > the higher resource usage.
> >
> > SVV2: I mention the DefaultReplicationPolicy to provide examples. I don't
> > think it is required. The actual requirement related to the
> > ReplicationPolicy is that the policy should be able to correctly tell
> which
> > topic was replicated from which cluster. Because of this,
> > IdentityReplicationPolicy would not work, but DefaultReplicationPolicy,
> or
> > any other ReplicationPolicy implementations with a correctly implemented
> > "topicSource" method should work. I will make an explicit note of this in
> > the KIP.
> >
> > Thank you,
> > Daniel
> >
> > Viktor Somogyi-Vass  ezt írta
> > (időpont: 2024. okt. 18., Pén 17:28):
> >
> > > Hey Dan,
> > >
> > > I think this is a very useful idea. Two questions:
> > >
> > > SVV1: Do you think we need the feature flag at all? I know that not
> having
> > > this flag may technically render the KIP unnecessary (however it may
> still
> > > be useful to discuss this topic and create a concensus). As you wrote
> in
> > > the KIP, we may be able to look up the target and source topics and if
> we
> > > can do this, we can probably detect if the replication is one-way or
> > > prefixless (identity). So that means we don't need this flag to control
> > > when we want to use this. Then it is really just there to act as
> something
> > > that can turn the feature on and off if needed, but I'm not really
> sure if
> > > there is a great risk in just enabling this by default. If we really
> just
> > > turn back the B -> A checkpoints and save them in the A -> B, then
> maybe
> > > it's not too risky and users would get this immediately by just
> upgrading.
> > >
> > > SVV2: You write that we need DefaultReplicationPolicy to use this
> feature,
> > > but most of the functionality is there on interface level in
> > > ReplicationPolicy. Is there anything that is missing from there and if
> so,
> > > what do you think about pulling it into the interface? If this
> improvement
> > > only works with the default replication policy, then it's somewhat
> limiting
> > > as users may have their own policy for various reasons, but if we can
> make
> > > it work on the interface level, then we could provide this feature to
> > > everyone. Of course there can be replication policies like the
> identity one
> > > that by design disallows this feature, but for that, see my previous
> point.
> > >
> > > Best,
> > > Viktor
> > >
> > > On Fri, Oct 18, 2024 at 3:30 PM Dániel Urbán 
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > I'd like to start the discussion on KIP-1098: Reverse Checkpointing (
> > > >
> > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1098%3A+Reverse+Checkpointing
> > > > )
> > > > which aims to minimize message reprocessing for consumers in
> failbacks.
> > > >
> > > > TIA,
> > > > Daniel
> > > >
> > >
>

[jira] [Created] (KAFKA-17846) ClientTelemetryReporter does not log trace-level message

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-17846:
--

 Summary: ClientTelemetryReporter does not log trace-level message
 Key: KAFKA-17846
 URL: https://issues.apache.org/jira/browse/KAFKA-17846
 Project: Kafka
  Issue Type: Bug
Reporter: Chia-Ping Tsai
Assignee: Wei-Ting Chen


see 
https://github.com/apache/kafka/blob/6e8df2951d8a93e0c4197d1054b0c4dec9e1f289/clients/src/main/java/org/apache/kafka/common/telemetry/internals/ClientTelemetryReporter.java#L340

we should revere the condition :)



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

[jira] [Created] (KAFKA-17847) Avoid the extra bytes copy when compressing telemetry payload

[Chia-Ping Tsai (Jira)]

Chia-Ping Tsai created KAFKA-17847:
--

 Summary: Avoid the extra bytes copy when compressing telemetry 
payload 
 Key: KAFKA-17847
 URL: https://issues.apache.org/jira/browse/KAFKA-17847
 Project: Kafka
  Issue Type: Improvement
Reporter: Chia-Ping Tsai
Assignee: Wei-Ting Chen


https://github.com/apache/kafka/blob/6e8df2951d8a93e0c4197d1054b0c4dec9e1f289/clients/src/main/java/org/apache/kafka/common/telemetry/internals/ClientTelemetryReporter.java#L710

`createPayload should return `MetricsData`, and then leverage 
MetricsData#writeTo to compress the data, avoiding extra byte copying.



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

Re: [DISCUSS] KIP-1088: Replace KafkaClientSupplier with KafkaClientInterceptor

[Sophie Blee-Goldman]

I think I can answer some of Bruno's questions:

BC2:
We want access to the configs for the individual client. For example, in
our implementation, we need to grab the clientId in order to configure our
wrapper. IIRC we also access some other configs so just passing in the
clientId wouldn't necessarily work. Providing the configs doesn't seem to
hurt anyways

BC4:
I think there is some confusion in how we have been describing this
"Interceptor" until now. My understanding is that we actually do intend to
still allow users to delegate to another client, for example a MockClient.
For another example, in our implementation of the global consumer we do
some things quite differently from the "default" implementation and it
would be problematic for us to have Streams call the methods on the "base"
client and pass in the returned value, rather than allowing us to intercept
the call itself. Happy to go into more detail if necessary but this simply
would not work for us.

This actually does make me wonder whether we really need to migrate from
the "ClientSupplier" to the "ClientInterceptor" in the first place. In
other words, since we allow clients calls to be delegated (eg to mock
clients instead of the "real" client) and have introduced the
StreamsConsumer interface for all the new Streams-group-specific methods
that will be needed for KIP-1071, why do we even have to enforce that users
only "wrap" the passed-in client?

What if we instead avoid deprecating the KafkaClientSupplier, and instead
deprecate only the `public Consumer getMainConsumer(...)` method while
adding this new method:

 public StreamsConsumer getStreamsConsumer(final StreamsConsumer
delegateStreamsConsumer, final Map<> configs);

For one thing, if the only thing we actually need to change is the main
consumer, it makes much more sense to replace only thing vs migrating over
to an entirely different (yet strikingly similar) API. And the only reason
the #getStreamsConsumer method needs to pass in the StreamsConsumer
constructed by Streams (ie the delegateStreamsConsumer) is that the
constructor for this kind of consumer is not a public API. There's no need
to change any of the other client methods.

Thoughts?

On Mon, Oct 14, 2024 at 1:21 PM Bill Bejeck  wrote:

> HI All,
>
> Matthias - thanks for the KIP!
>
> I'm in favor of this proposal, but I'd like to summarize my understanding
> to ensure I'm getting everything.
>
> 1. KafkaStreams will remain in control of creating the client unless the
> user overrides that behavior (I think this would be a rare case).
> Although we can't wholly enforce this creation rule, it's evident that
> doing so breaks the contract, and users will need to understand they are on
> their own at that point.
> Of course, providing a MockConsumer instance would be supported or expected
> for testing.
>
> 2. It allows users to override given method(s), in other words,
> "cherry-pick" the behavior to modify easily, rather than implementing their
> own client with overridden methods. (Admittedly, the difference between the
> two approaches is minor.)
>
> 3. While we could only provide a `StreamsConsumer` and add methods as
> needed, providing an interceptor seems more direct in guiding users on how
> to modify behavior.
>
> I'm good with the KIP as it stands now. I get what Sophie and Bruno are
> alluding to with the naming, so maybe a name of `WrappedX` would be more
> appropriate, but I don't have a strong opinion.
>
> Thanks,
> Bill
>
> On Mon, Oct 14, 2024 at 4:17 AM Bruno Cadonna  wrote:
>
> > Hi,
> >
> > Thanks for the KIP!
> >
> >
> > BC1.
> > I echo point S3 from Sophie. I find it quite confusing having those
> > methods return an interceptor that is used as a client in the Streams
> > code. Naming might already do the trick. Something like
> > Intercepted(Admin|StreamsConsumer|Consumer|Producer) or
> > Wrapped(Admin|StreamsConsumer|Consumer|Producer) come to my mind.
> >
> > Related to this: Why is the interface with all the wrap* methods also
> > called Interceptor? The functionality is quite different from the other
> > interceptors.
> >
> >
> > BC2.
> > Why do you not use interfaces instead of the classes for the clients in
> > the wrap* signatures? We just want to intercept the calls to the
> > interface, right?
> >
> > Related to this, why do you pass-in also the configs of the clients, if
> > you only want to wrap the calls to them?
> >
> >
> > BC3.
> > Why do we need KafkaStreamsConsumer in the public API? Isn't the
> > StreamsConsumer interface enough?
> >
> >
> > BC4.
> > I am wondering, whether a kind of observer pattern would be better. That
> > means, in Streams we do not call the interceptor but we call the client
> > and for each call we also call the corresponding method on the passed in
> > object -- basically the user implements callbacks.
> >
> > That would make it even clearer that you should not inject your own
> > client implementations since we remove the user's object from the direct
> > call 

[jira] [Created] (KAFKA-17843) Add integration tests to validate clients close when closed just after instantiation

[Apoorv Mittal (Jira)]

Apoorv Mittal created KAFKA-17843:
-

 Summary: Add integration tests to validate clients close when 
closed just after instantiation
 Key: KAFKA-17843
 URL: https://issues.apache.org/jira/browse/KAFKA-17843
 Project: Kafka
  Issue Type: Improvement
Reporter: Apoorv Mittal
Assignee: Apoorv Mittal


We have seen an issue with Kafka Consumer which trigger thread wait when 
consumer is closed just after instantiation. Though the 
[issue|https://issues.apache.org/jira/browse/KAFKA-17731] has been fixed now 
but write test cases to avoid any such issue in future.



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

Re: [VOTE] KIP-1080: Fix the typo: `maxlifeTimeMs` in CreateDelegationTokenOptions

[黃竣陽]

Hello everyone,

I hope you're all doing well. Since the vote has been pending for over three 
weeks, 

I’d like to proceed with pushing it manually. 

Thank you for your attention.

Best regards,
Jiunn-Yang

> 黃竣陽  於 2024年9月28日 上午10:04 寫道：
> 
> Hello everyone,
> I hope this message finds you well.
> As the vote has been pending for more than two weeks, I would like to push it
> manually.
> 
> Thank you for your attention.
> Best regards,
> Jiunn-Yang
> 
>> Lianet M.  於 2024年9月10日 晚上11:06 寫道：
>> 
>> Hello,
>> 
>> Thanks for updating the KIP. Looks good to me now.
>> 
>> +1 (binding)
>> 
>> Lianet
>> 
>> 
>> On Thu, Sep 5, 2024, 8:29 p.m. 黃竣陽  wrote:
>> 
>>> It make sense to me, I will change to
>>> `CreateDelegationTokenRequestData.setMaxLifetimeMs`
>>> 
 Chia-Ping Tsai  於 2024年9月5日 晚上11:22 寫道：
 
> it aligns better with the RPC field (max_lifetime_ms)
 
 That makes sense to me. +1 to align it
 
 Best,
 Chia-Ping
 
 Lianet M.  於 2024年9月5日 週四 下午11:13寫道：
 
> Hey all, just one small comment: shouldn't the new method be named "
> maxLifetimeMs()" (Lifetime vs LifeTime)? I believe it's the right
>>> spelling,
> but mostly, it aligns better with the RPC field (max_lifetime_ms), that
> generates a CreateDelegationTokenRequestData.maxLifetimeMs() and
> CreateDelegationTokenRequestData.setMaxLifetimeMs(...)
> 
> Thanks!
> 
> Lianet
> 
> On Thu, Sep 5, 2024 at 9:36 AM Chia-Ping Tsai 
>>> wrote:
> 
>> +1 (binding)
>> 
>> 黃竣陽  於 2024年9月5日 週四 下午9:08寫道：
>> 
>>> Hello everyone,
>>> 
>>> I would like to call for a vote on KIP-1080: <
>>> 
>> 
> 
>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1080%3A+Fix+the+typo%3A+%60maxlifeTimeMs%60+in+CreateDelegationTokenOptions
 
>>> 
>>> The discussion can be found here:
>>> 
>>> 
>>> Best regards,
>>> Jiunn-Yang
>> 
> 
>>> 
>>> 
> 

Re: [DISCUSS] KIP-1098: Reverse Checkpointing

[Dániel Urbán]

Hi Viktor,

Thank you for the comments!

SVV1: I think the feature has some performance implications. If the reverse
checkpointing is enabled, task startup will be possibly slower, since it
will need to consume from a second offset-syncs topic; and it will also use
more memory, to keep the second offset-sync history. Additionally, it is
also possible to have an offset-syncs topic present without an actual,
opposite flow being active - I think only users can tell if the reverse
checkpointing should be active, and they should be the one opting in for
the higher resource usage.

SVV2: I mention the DefaultReplicationPolicy to provide examples. I don't
think it is required. The actual requirement related to the
ReplicationPolicy is that the policy should be able to correctly tell which
topic was replicated from which cluster. Because of this,
IdentityReplicationPolicy would not work, but DefaultReplicationPolicy, or
any other ReplicationPolicy implementations with a correctly implemented
"topicSource" method should work. I will make an explicit note of this in
the KIP.

Thank you,
Daniel

Viktor Somogyi-Vass  ezt írta
(időpont: 2024. okt. 18., Pén 17:28):

> Hey Dan,
>
> I think this is a very useful idea. Two questions:
>
> SVV1: Do you think we need the feature flag at all? I know that not having
> this flag may technically render the KIP unnecessary (however it may still
> be useful to discuss this topic and create a concensus). As you wrote in
> the KIP, we may be able to look up the target and source topics and if we
> can do this, we can probably detect if the replication is one-way or
> prefixless (identity). So that means we don't need this flag to control
> when we want to use this. Then it is really just there to act as something
> that can turn the feature on and off if needed, but I'm not really sure if
> there is a great risk in just enabling this by default. If we really just
> turn back the B -> A checkpoints and save them in the A -> B, then maybe
> it's not too risky and users would get this immediately by just upgrading.
>
> SVV2: You write that we need DefaultReplicationPolicy to use this feature,
> but most of the functionality is there on interface level in
> ReplicationPolicy. Is there anything that is missing from there and if so,
> what do you think about pulling it into the interface? If this improvement
> only works with the default replication policy, then it's somewhat limiting
> as users may have their own policy for various reasons, but if we can make
> it work on the interface level, then we could provide this feature to
> everyone. Of course there can be replication policies like the identity one
> that by design disallows this feature, but for that, see my previous point.
>
> Best,
> Viktor
>
> On Fri, Oct 18, 2024 at 3:30 PM Dániel Urbán 
> wrote:
>
> > Hi everyone,
> >
> > I'd like to start the discussion on KIP-1098: Reverse Checkpointing (
> >
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1098%3A+Reverse+Checkpointing
> > )
> > which aims to minimize message reprocessing for consumers in failbacks.
> >
> > TIA,
> > Daniel
> >
>

Re: [DISCUSS] Apache Kafka 4.0.0 release

[David Jacot]

Hi TengYao,

Of course! I just added it to the release plan.

Best,
David

On Sun, Oct 20, 2024 at 8:36 PM Colin McCabe  wrote:

> Hi TengYao Chi,
>
> The KIP freeze for Apache Kafka 4.0 is. November 20th. So if KIP-1092 has
> been accepted already, it should make it into 4.0 without any further
> discussion (assuming the code is ready by feature freeze.)
>
> Cheers,
> Colin
>
> On Fri, Oct 18, 2024, at 20:32, TengYao Chi wrote:
> > Hi David,
> >
> > I would like to request the inclusion of KIP-1092 in the 4.0 release
> plan.
> > This KIP is newly accepted, and I believe it will bring valuable
> > enhancements for both the Consumer and Kafka Streams components.
> >
> > Thank you for considering this addition.
> >
> > Best,
> > TengYao
> >
> > Colin McCabe  於 2024年10月11日 週五 上午12:22寫道：
> >
> >> Yes (although I don't believe there's a JIRA for that specifically yet.)
> >>
> >> best,
> >> Colin
> >>
> >>
> >> On Thu, Oct 10, 2024, at 09:11, David Jacot wrote:
> >> > Hi Colin,
> >> >
> >> > Thanks. That seems perfect. Does it include removing --zookeeper from
> the
> >> > command line tools (e.g. kafka-configs)?
> >> >
> >> > Best,
> >> > David
> >> >
> >> > On Thu, Oct 10, 2024 at 6:06 PM Colin McCabe 
> wrote:
> >> >
> >> >> Hi David & Luke,
> >> >>
> >> >> We have been using https://issues.apache.org/jira/browse/KAFKA-17611
> as
> >> >> the umbrella JIRA for ZK removal tasks.  Progress has been pretty
> >> rapid, I
> >> >> do think we will get there by January. (Well hopefully even earlier
> :)
> >> >>
> >> >> best,
> >> >> Colin
> >> >>
> >> >>
> >> >> On Thu, Oct 10, 2024, at 05:55, David Jacot wrote:
> >> >> > Hi Luke,
> >> >> >
> >> >> > That's a good point. I think that we should try to stick to the
> dates
> >> >> > though. In my opinion, we should ensure that ZK and all the related
> >> >> public
> >> >> > facing apis are gone in 4.0 by code freeze. The simplest way would
> be
> >> to
> >> >> > have an epic for the removal with all the related tasks. We can
> then
> >> mark
> >> >> > it as a blocker for 4.0. We may already have one. Let me search
> >> around.
> >> >> >
> >> >> > Best,
> >> >> > David
> >> >> >
> >> >> > On Thu, Oct 10, 2024 at 2:43 PM Luke Chen 
> wrote:
> >> >> >
> >> >> >> Hi David,
> >> >> >>
> >> >> >> The release plan looks good to me.
> >> >> >>
> >> >> >> But since the 4.0 release is a release without ZK, I'm wondering
> if
> >> we
> >> >> >> should list some release criteria for it?
> >> >> >> The Problem I can imagine is like, when the code freeze date is
> >> reached,
> >> >> >> but there are still many ZK removal tasks open, what should we do
> >> with
> >> >> >> them? We can remove the rest of codes in later releases, but if
> there
> >> >> are
> >> >> >> still some public APIs related to ZK open for users to use, is
> that
> >> >> still
> >> >> >> OK to release 4.0? Ex: The `--zookeeper` option in
> kafka-configs.sh?
> >> >> >>
> >> >> >> Instead of only using time-based management in v4.0, I'm
> suggesting
> >> we
> >> >> >> should list some "must-do" tasks and track them when milestone
> date
> >> >> >> approaches. And we can discuss with the community if there are
> some
> >> >> delayed
> >> >> >> tasks. Does that make sense?
> >> >> >>
> >> >> >> Thanks.
> >> >> >> Luke
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Mon, Oct 7, 2024 at 9:29 PM David Jacot
> >>  >> >> >
> >> >> >> wrote:
> >> >> >>
> >> >> >> > Hi all,
> >> >> >> >
> >> >> >> > I have drafted the release plan for Apache Kafka 4.0.0:
> >> >> >> >
> >> https://cwiki.apache.org/confluence/display/KAFKA/Release+Plan+4.0.0.
> >> >> >> > Please take a look and let me know what you think.
> >> >> >> >
> >> >> >> > I would also appreciate it if you could review the list of KIPs
> >> that
> >> >> we
> >> >> >> > will ship in this release. I took the list from the approved
> list
> >> in
> >> >> the
> >> >> >> > wiki but I am pretty sure that the list is not accurate.
> >> >> >> >
> >> >> >> > Best,
> >> >> >> > Davud
> >> >> >> >
> >> >> >> > On Wed, Sep 25, 2024 at 5:02 AM Luke Chen 
> >> wrote:
> >> >> >> >
> >> >> >> > > +1 from me.
> >> >> >> > > Since v4.0 will be a huge change release, I'm not sure if you
> >> need
> >> >> >> > another
> >> >> >> > > person (vice release manager?) to help on releasing tasks.
> >> >> >> > > If so, I'm willing to help.
> >> >> >> > >
> >> >> >> > > Thanks.
> >> >> >> > > Luke
> >> >> >> > >
> >> >> >> > > On Wed, Sep 25, 2024 at 1:33 AM Colin McCabe <
> cmcc...@apache.org
> >> >
> >> >> >> wrote:
> >> >> >> > >
> >> >> >> > > > +1. Thanks, David.
> >> >> >> > > >
> >> >> >> > > > best,
> >> >> >> > > > Colin
> >> >> >> > > >
> >> >> >> > > > On Mon, Sep 23, 2024, at 10:11, Chris Egerton wrote:
> >> >> >> > > > > Thanks David! +1
> >> >> >> > > > >
> >> >> >> > > > > On Mon, Sep 23, 2024, 13:07 José Armando García Sancio
> >> >> >> > > > >  wrote:
> >> >> >> > > > >
> >> >> >> > > > >> +1, thanks for volunteering David!
> >> >> >> > > > >>
> >> >> >> > > > >> On Mon, Sep 23,

Re: [DISCUSS] KIP-1098: Reverse Checkpointing

[Mickael Maison]

Hi Daniel,

I've not had time to take a close look at the KIP but my initial
feedback would be to adjust the name to make it clear it's about
MirrorMaker.
The word "checkpoint" has several meanings in Kafka and from the
current KIP name it's not clear if it's about KRaft, Streams or
Connect.

Thanks,
Mickael

On Mon, Oct 21, 2024 at 2:55 PM Dániel Urbán  wrote:
>
> Hi Viktor,
>
> Thank you for the comments!
>
> SVV1: I think the feature has some performance implications. If the reverse
> checkpointing is enabled, task startup will be possibly slower, since it
> will need to consume from a second offset-syncs topic; and it will also use
> more memory, to keep the second offset-sync history. Additionally, it is
> also possible to have an offset-syncs topic present without an actual,
> opposite flow being active - I think only users can tell if the reverse
> checkpointing should be active, and they should be the one opting in for
> the higher resource usage.
>
> SVV2: I mention the DefaultReplicationPolicy to provide examples. I don't
> think it is required. The actual requirement related to the
> ReplicationPolicy is that the policy should be able to correctly tell which
> topic was replicated from which cluster. Because of this,
> IdentityReplicationPolicy would not work, but DefaultReplicationPolicy, or
> any other ReplicationPolicy implementations with a correctly implemented
> "topicSource" method should work. I will make an explicit note of this in
> the KIP.
>
> Thank you,
> Daniel
>
> Viktor Somogyi-Vass  ezt írta
> (időpont: 2024. okt. 18., Pén 17:28):
>
> > Hey Dan,
> >
> > I think this is a very useful idea. Two questions:
> >
> > SVV1: Do you think we need the feature flag at all? I know that not having
> > this flag may technically render the KIP unnecessary (however it may still
> > be useful to discuss this topic and create a concensus). As you wrote in
> > the KIP, we may be able to look up the target and source topics and if we
> > can do this, we can probably detect if the replication is one-way or
> > prefixless (identity). So that means we don't need this flag to control
> > when we want to use this. Then it is really just there to act as something
> > that can turn the feature on and off if needed, but I'm not really sure if
> > there is a great risk in just enabling this by default. If we really just
> > turn back the B -> A checkpoints and save them in the A -> B, then maybe
> > it's not too risky and users would get this immediately by just upgrading.
> >
> > SVV2: You write that we need DefaultReplicationPolicy to use this feature,
> > but most of the functionality is there on interface level in
> > ReplicationPolicy. Is there anything that is missing from there and if so,
> > what do you think about pulling it into the interface? If this improvement
> > only works with the default replication policy, then it's somewhat limiting
> > as users may have their own policy for various reasons, but if we can make
> > it work on the interface level, then we could provide this feature to
> > everyone. Of course there can be replication policies like the identity one
> > that by design disallows this feature, but for that, see my previous point.
> >
> > Best,
> > Viktor
> >
> > On Fri, Oct 18, 2024 at 3:30 PM Dániel Urbán 
> > wrote:
> >
> > > Hi everyone,
> > >
> > > I'd like to start the discussion on KIP-1098: Reverse Checkpointing (
> > >
> > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1098%3A+Reverse+Checkpointing
> > > )
> > > which aims to minimize message reprocessing for consumers in failbacks.
> > >
> > > TIA,
> > > Daniel
> > >
> >

[jira] [Resolved] (KAFKA-17031) Make configurations public

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-17031.
--
Resolution: Fixed

> Make configurations public
> --
>
> Key: KAFKA-17031
> URL: https://issues.apache.org/jira/browse/KAFKA-17031
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Christo Lolov
>Assignee: Federico Valeri
>Priority: Major
> Fix For: 3.9.0
>
>
> *Summary*
> We introduce 3 new configurations as part of this KIP. Up to now they have 
> been defined as internal only. We need to change said configurations to 
> public prior to the release.
>  
> Also need to deprecate "remote.log.manager.thread.pool.size" config.



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

[jira] [Created] (KAFKA-17848) Resolve reliability issue on the broker post moving delayed share fetch purgatory to ReplicaManager

[Abhinav Dixit (Jira)]

Abhinav Dixit created KAFKA-17848:
-

 Summary: Resolve reliability issue on the broker post moving 
delayed share fetch purgatory to ReplicaManager
 Key: KAFKA-17848
 URL: https://issues.apache.org/jira/browse/KAFKA-17848
 Project: Kafka
  Issue Type: Sub-task
Reporter: Abhinav Dixit
Assignee: Abhinav Dixit


Post merging [https://github.com/apache/kafka/pull/17437] , I see a reliability 
issue which is consistent when using share consumers with multiple topic 
partitions. The broker is unable to consume 1,000,000 records with 10 share 
consumers. It seems like some threads are going in a deadlock or fetch threads 
are not completing.



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

[jira] [Created] (KAFKA-17845) UpdateRaftVoterResponse has incorrect default value fallbacks

[Anton Agestam (Jira)]

Anton Agestam created KAFKA-17845:
-

 Summary: UpdateRaftVoterResponse has incorrect default value 
fallbacks
 Key: KAFKA-17845
 URL: https://issues.apache.org/jira/browse/KAFKA-17845
 Project: Kafka
  Issue Type: Bug
Affects Versions: 3.9.0
Reporter: Anton Agestam


This was discovered through property testing for upgrading kio to Kafka 
3.9.0-rc2 schema.

We have tests in place to assert that our protocol serializer implementation is 
sync with upstream Kafka.

The test discovered a discrepancy between kio and Kafka for this instance:

 
{code:java}
E           instance=UpdateRaftVoterResponse(
E               throttle_time=datetime.timedelta(0),
E               error_code=,
E               current_leader=CurrentLeader(
E                   leader_id=-1,
E                   leader_epoch=-1,
E                   host='',
E                   port=0,
E               ),
E           ), {code}
kio serializes this as `"AP//AQAO//8BAAA="` while Kafka 
serializes it as `"AP//AA=="` (base 64 encoded bytes).

This is as if the `host` and `port` fields have defaults of empty string and 
zero, but they do not. 

This looks to me like the behavior for [deserializing a message from a previous 
version 
|https://github.com/apache/kafka/tree/trunk/clients/src/main/resources/common/message#deserializing-messages]
 is incorrectly kicking in here.

I would expect to either see the defaults declared in the schema, or for this 
model to not exercise this "omit the nested entity" behavior at all, since all 
of the fields of the nested entity do not have default values.

 



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

[jira] [Resolved] (KAFKA-17794) kafka-storage format must require KIP-853 flags unless controller.quorum.voters is set

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-17794.
--
Resolution: Fixed

> kafka-storage format must require KIP-853 flags unless 
> controller.quorum.voters is set
> --
>
> Key: KAFKA-17794
> URL: https://issues.apache.org/jira/browse/KAFKA-17794
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Colin McCabe
>Assignee: Colin McCabe
>Priority: Blocker
> Fix For: 3.9.0
>
>
> kafka-storage format must require KIP-853 flags unless 
> controller.quorum.voters is set



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

Re: [VOTE] 3.9.0 RC2

[Anton Agestam]

Hi everyone,

I have found a protocol serialization bug that surfaces only with one of
the entities introduced for KIP-853 (UpdateRaftVoterResponse).

Due to the irreversible implications this might have once merged, I'd argue
that this needs to be considered a release blocker.

https://issues.apache.org/jira/browse/KAFKA-17845

BR,
Anton

Den tors 10 okt. 2024 kl 23:16 skrev Colin McCabe :

> This is the second candidate for the release of Apache Kafka 3.9.0. I have
> titled it rc2 since I had an rc1 which got very far, even to the point of
> pushing tags and docker images, before I spotted an issue. So rather than
> mutate the tags, I decided to skip over rc1.
>
> - This is a major release, the final one in the 3.x line. (There may of
> course be other minor releases in this line, such as 3.9.1.)
> - Tiered storage will be considered production-ready in this release.
> - This will be the final major release to feature the deprecated ZooKeeper
> mode.
>
> This release includes the following KIPs:
> - KIP-853: Support dynamically changing KRaft controller membership
> - KIP-1057: Add remote log metadata flag to the dump log tool
> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
> - KIP-1040: Improve handling of nullable values in InsertField,
> ExtractField, and other transformations
> - KIP-1031: Control offset translation in MirrorSourceConnector
> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
> during processing
> - KIP-1017: Health check endpoint for Kafka Connect
> - KIP-1025: Optionally URL-encode clientID and clientSecret in
> authorization header
> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
> - KIP-950: Tiered Storage Disablement
> - KIP-956: Tiered Storage Quotas
>
> Release notes for the 3.9.0 release:
> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/RELEASE_NOTES.html
>
> *** Please download, test and vote by October 16, 2024.
>
> Kafka's KEYS file containing PGP keys we use to sign the release:
> https://kafka.apache.org/KEYS
>
> * Release artifacts to be voted upon (source and binary):
> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/
>
> * Docker release artifacts to be voted upon:
> apache/kafka:3.9.0-rc2
> apache/kafka-native:3.9.0-rc2
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/javadoc/
>
> * Documentation:
> https://kafka.apache.org/39/documentation.html
>
> * Protocol:
> https://kafka.apache.org/39/protocol.html
>
> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc2 tag:
> https://github.com/apache/kafka/releases/tag/3.9.0-rc2
>
> * Successful Docker Image Github Actions Pipeline for 3.9 branch:
> Docker Build Test Pipeline (JVM):
> https://github.com/apache/kafka/actions/runs/11281563007
> Docker Build Test Pipeline (Native):
> https://github.com/apache/kafka/actions/runs/11281608809
>
> Thanks to everyone who helped with this release candidate, either by
> contributing code, testing, or documentation.
>
> Regards,
> Colin
>

[jira] [Resolved] (KAFKA-17545) Get rid of fetch queue in SharePartitionManager

[Jun Rao (Jira)]

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

Jun Rao resolved KAFKA-17545.
-
Fix Version/s: 4.0.0
 Assignee: Apoorv Mittal  (was: Abhinav Dixit)
   Resolution: Fixed

Merged the PR to trunk.

> Get rid of fetch queue in SharePartitionManager
> ---
>
> Key: KAFKA-17545
> URL: https://issues.apache.org/jira/browse/KAFKA-17545
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: Abhinav Dixit
>Assignee: Apoorv Mittal
>Priority: Major
> Fix For: 4.0.0
>
>
> Since we are fetching from the share fetch purgatory, the fetch queue becomes 
> redundant. Hence, we should get rid of it from Share Partition Manager. 
> Pointed out in review comment 
> https://github.com/apache/kafka/pull/17177#pullrequestreview-2301365314



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

Re: [VOTE] 3.9.0 RC2

[Colin McCabe]

Hi Anton,

I replied on the JIRA. I do not think this is a bug, you just failed to account 
for implicit defaults in your protocol code. That is, 0 is the default of 
numeric fields if no other default is specified, etc.

best,
Colin

On Mon, Oct 21, 2024, at 08:07, Anton Agestam wrote:
> Hi everyone,
>
> I have found a protocol serialization bug that surfaces only with one of
> the entities introduced for KIP-853 (UpdateRaftVoterResponse).
>
> Due to the irreversible implications this might have once merged, I'd argue
> that this needs to be considered a release blocker.
>
> https://issues.apache.org/jira/browse/KAFKA-17845
>
> BR,
> Anton
>
> Den tors 10 okt. 2024 kl 23:16 skrev Colin McCabe :
>
>> This is the second candidate for the release of Apache Kafka 3.9.0. I have
>> titled it rc2 since I had an rc1 which got very far, even to the point of
>> pushing tags and docker images, before I spotted an issue. So rather than
>> mutate the tags, I decided to skip over rc1.
>>
>> - This is a major release, the final one in the 3.x line. (There may of
>> course be other minor releases in this line, such as 3.9.1.)
>> - Tiered storage will be considered production-ready in this release.
>> - This will be the final major release to feature the deprecated ZooKeeper
>> mode.
>>
>> This release includes the following KIPs:
>> - KIP-853: Support dynamically changing KRaft controller membership
>> - KIP-1057: Add remote log metadata flag to the dump log tool
>> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
>> - KIP-1040: Improve handling of nullable values in InsertField,
>> ExtractField, and other transformations
>> - KIP-1031: Control offset translation in MirrorSourceConnector
>> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
>> during processing
>> - KIP-1017: Health check endpoint for Kafka Connect
>> - KIP-1025: Optionally URL-encode clientID and clientSecret in
>> authorization header
>> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
>> - KIP-950: Tiered Storage Disablement
>> - KIP-956: Tiered Storage Quotas
>>
>> Release notes for the 3.9.0 release:
>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/RELEASE_NOTES.html
>>
>> *** Please download, test and vote by October 16, 2024.
>>
>> Kafka's KEYS file containing PGP keys we use to sign the release:
>> https://kafka.apache.org/KEYS
>>
>> * Release artifacts to be voted upon (source and binary):
>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/
>>
>> * Docker release artifacts to be voted upon:
>> apache/kafka:3.9.0-rc2
>> apache/kafka-native:3.9.0-rc2
>>
>> * Maven artifacts to be voted upon:
>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>>
>> * Javadoc:
>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/javadoc/
>>
>> * Documentation:
>> https://kafka.apache.org/39/documentation.html
>>
>> * Protocol:
>> https://kafka.apache.org/39/protocol.html
>>
>> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc2 tag:
>> https://github.com/apache/kafka/releases/tag/3.9.0-rc2
>>
>> * Successful Docker Image Github Actions Pipeline for 3.9 branch:
>> Docker Build Test Pipeline (JVM):
>> https://github.com/apache/kafka/actions/runs/11281563007
>> Docker Build Test Pipeline (Native):
>> https://github.com/apache/kafka/actions/runs/11281608809
>>
>> Thanks to everyone who helped with this release candidate, either by
>> contributing code, testing, or documentation.
>>
>> Regards,
>> Colin
>>

[jira] [Resolved] (KAFKA-17845) UpdateRaftVoterResponse has incorrect default value fallbacks

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-17845.
--
Resolution: Invalid

> UpdateRaftVoterResponse has incorrect default value fallbacks
> -
>
> Key: KAFKA-17845
> URL: https://issues.apache.org/jira/browse/KAFKA-17845
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.9.0
>Reporter: Anton Agestam
>Priority: Major
>
> This was discovered through property testing for upgrading kio to Kafka 
> 3.9.0-rc2 schema.
> We have tests in place to assert that our protocol serializer implementation 
> is sync with upstream Kafka.
> The test discovered a discrepancy between kio and Kafka for this instance:
>  
> {code:java}
> E           instance=UpdateRaftVoterResponse(
> E               throttle_time=datetime.timedelta(0),
> E               error_code=,
> E               current_leader=CurrentLeader(
> E                   leader_id=-1,
> E                   leader_epoch=-1,
> E                   host='',
> E                   port=0,
> E               ),
> E           ), {code}
> kio serializes this as `"AP//AQAO//8BAAA="` while Kafka 
> serializes it as `"AP//AA=="` (base 64 encoded bytes).
> This is as if the `host` and `port` fields have defaults of empty string and 
> zero, but they do not. 
> This looks to me like the behavior for [deserializing a message from a 
> previous version 
> |https://github.com/apache/kafka/tree/trunk/clients/src/main/resources/common/message#deserializing-messages]
>  is incorrectly kicking in here.
> I would expect to either see the defaults declared in the schema, or for this 
> model to not exercise this "omit the nested entity" behavior at all, since 
> all of the fields of the nested entity do not have default values.
>  



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

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

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-17755) AbstractPartitionAssignor can not enable RackAwareAssignment base on lead rack mode

[Jerry Cai (Jira)]

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

Jerry Cai resolved KAFKA-17755.
---
Fix Version/s: 3.8.1
 Reviewer: Rajini Sivaram
   Resolution: Fixed

> AbstractPartitionAssignor can not enable RackAwareAssignment base on lead 
> rack mode
> ---
>
> Key: KAFKA-17755
> URL: https://issues.apache.org/jira/browse/KAFKA-17755
> Project: Kafka
>  Issue Type: Bug
>  Components: consumer
>Affects Versions: 3.7.0, 3.8.0, 3.7.1
>Reporter: Jerry Cai
>Assignee: Jerry Cai
>Priority: Critical
> Fix For: 3.8.1
>
>
> During my local test and debug, I noticed that the below logical is in 
> correct, it needs to change 
> from   !racksPerPartition.values().stream().allMatch(partitionRacks::equals)  
> to  racksPerPartition.values().stream().allMatch(partitionRacks::equals)
>  
>  
>  
> current logical 
> {code:java}
> protected boolean useRackAwareAssignment(Set consumerRacks, 
> Set partitionRacks, Map> 
> racksPerPartition) {
> if (consumerRacks.isEmpty() || Collections.disjoint(consumerRacks, 
> partitionRacks))
> return false;
> else if (preferRackAwareLogic)
> return true;
> else {
> return 
> !racksPerPartition.values().stream().allMatch(partitionRacks::equals);
> }
> }
>  {code}
>  
> expected logical 
> {code:java}
> protected boolean useRackAwareAssignment(Set consumerRacks, 
> Set partitionRacks, Map> 
> racksPerPartition) {
> if (consumerRacks.isEmpty() || Collections.disjoint(consumerRacks, 
> partitionRacks))
> return false;
> else if (preferRackAwareLogic)
> return true;
> else {
> return 
> racksPerPartition.values().stream().allMatch(partitionRacks::equals);
> }
> }
>  {code}



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

[VOTE] 3.9.0 RC3

[Colin McCabe]

This is the third candidate for the release of Apache Kafka 3.9.0. I have 
titled it rc3 since I had an rc1 which got very far, even to the point of 
pushing tags and docker images, before I spotted an issue. So rather than 
mutate the tags, I decided to skip over rc1.

- This is a major release, the final one in the 3.x line. (There may of course 
be other minor releases in this line, such as 3.9.1.)
- Tiered storage will be considered production-ready in this release.
- This will be the final major release to feature the deprecated ZooKeeper mode.

This release includes the following KIPs:
- KIP-853: Support dynamically changing KRaft controller membership
- KIP-1057: Add remote log metadata flag to the dump log tool
- KIP-1049: Add config log.summary.interval.ms to Kafka Streams
- KIP-1040: Improve handling of nullable values in InsertField, ExtractField, 
and other transformations
- KIP-1031: Control offset translation in MirrorSourceConnector
- KIP-1033: Add Kafka Streams exception handler for exceptions occurring during 
processing
- KIP-1017: Health check endpoint for Kafka Connect
- KIP-1025: Optionally URL-encode clientID and clientSecret in authorization 
header
- KIP-1005: Expose EarliestLocalOffset and TieredOffset
- KIP-950: Tiered Storage Disablement
- KIP-956: Tiered Storage Quotas

Release notes for the 3.9.0 release:
https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc3/RELEASE_NOTES.html

*** Please download, test and vote by October 24, 2024.

Kafka's KEYS file containing PGP keys we use to sign the release:
https://kafka.apache.org/KEYS

* Release artifacts to be voted upon (source and binary):
https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc3/

* Docker release artifacts to be voted upon:
apache/kafka:3.9.0-rc3
apache/kafka-native:3.9.0-rc3

* Maven artifacts to be voted upon:
https://repository.apache.org/content/groups/staging/org/apache/kafka/

* Javadoc:
https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc3/javadoc/

* Documentation:
https://kafka.apache.org/39/documentation.html

* Protocol:
https://kafka.apache.org/39/protocol.html

* Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc3 tag:
https://github.com/apache/kafka/releases/tag/3.9.0-rc3

* Successful Docker Image Github Actions Pipeline for 3.9 branch:
Docker Build Test Pipeline (JVM): 
https://github.com/apache/kafka/actions/runs/11448325059
Docker Build Test Pipeline (Native): 
https://github.com/apache/kafka/actions/runs/11448338981

Thanks to everyone who helped with this release candidate, either by 
contributing code, testing, or documentation.

Regards,
Colin

Re: [VOTE] 3.9.0 RC2

[Colin McCabe]

Hi all,

I have posted a new release candidate, RC3. See the RC3 thread.

best,
Colin

On Mon, Oct 21, 2024, at 11:31, Colin McCabe wrote:
> Hi Anton,
>
> I replied on the JIRA. I do not think this is a bug, you just failed to 
> account for implicit defaults in your protocol code. That is, 0 is the 
> default of numeric fields if no other default is specified, etc.
>
> best,
> Colin
>
> On Mon, Oct 21, 2024, at 08:07, Anton Agestam wrote:
>> Hi everyone,
>>
>> I have found a protocol serialization bug that surfaces only with one of
>> the entities introduced for KIP-853 (UpdateRaftVoterResponse).
>>
>> Due to the irreversible implications this might have once merged, I'd argue
>> that this needs to be considered a release blocker.
>>
>> https://issues.apache.org/jira/browse/KAFKA-17845
>>
>> BR,
>> Anton
>>
>> Den tors 10 okt. 2024 kl 23:16 skrev Colin McCabe :
>>
>>> This is the second candidate for the release of Apache Kafka 3.9.0. I have
>>> titled it rc2 since I had an rc1 which got very far, even to the point of
>>> pushing tags and docker images, before I spotted an issue. So rather than
>>> mutate the tags, I decided to skip over rc1.
>>>
>>> - This is a major release, the final one in the 3.x line. (There may of
>>> course be other minor releases in this line, such as 3.9.1.)
>>> - Tiered storage will be considered production-ready in this release.
>>> - This will be the final major release to feature the deprecated ZooKeeper
>>> mode.
>>>
>>> This release includes the following KIPs:
>>> - KIP-853: Support dynamically changing KRaft controller membership
>>> - KIP-1057: Add remote log metadata flag to the dump log tool
>>> - KIP-1049: Add config log.summary.interval.ms to Kafka Streams
>>> - KIP-1040: Improve handling of nullable values in InsertField,
>>> ExtractField, and other transformations
>>> - KIP-1031: Control offset translation in MirrorSourceConnector
>>> - KIP-1033: Add Kafka Streams exception handler for exceptions occurring
>>> during processing
>>> - KIP-1017: Health check endpoint for Kafka Connect
>>> - KIP-1025: Optionally URL-encode clientID and clientSecret in
>>> authorization header
>>> - KIP-1005: Expose EarliestLocalOffset and TieredOffset
>>> - KIP-950: Tiered Storage Disablement
>>> - KIP-956: Tiered Storage Quotas
>>>
>>> Release notes for the 3.9.0 release:
>>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/RELEASE_NOTES.html
>>>
>>> *** Please download, test and vote by October 16, 2024.
>>>
>>> Kafka's KEYS file containing PGP keys we use to sign the release:
>>> https://kafka.apache.org/KEYS
>>>
>>> * Release artifacts to be voted upon (source and binary):
>>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/
>>>
>>> * Docker release artifacts to be voted upon:
>>> apache/kafka:3.9.0-rc2
>>> apache/kafka-native:3.9.0-rc2
>>>
>>> * Maven artifacts to be voted upon:
>>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>>>
>>> * Javadoc:
>>> https://dist.apache.org/repos/dist/dev/kafka/3.9.0-rc2/javadoc/
>>>
>>> * Documentation:
>>> https://kafka.apache.org/39/documentation.html
>>>
>>> * Protocol:
>>> https://kafka.apache.org/39/protocol.html
>>>
>>> * Tag to be voted upon (off 3.9 branch) is the 3.9.0-rc2 tag:
>>> https://github.com/apache/kafka/releases/tag/3.9.0-rc2
>>>
>>> * Successful Docker Image Github Actions Pipeline for 3.9 branch:
>>> Docker Build Test Pipeline (JVM):
>>> https://github.com/apache/kafka/actions/runs/11281563007
>>> Docker Build Test Pipeline (Native):
>>> https://github.com/apache/kafka/actions/runs/11281608809
>>>
>>> Thanks to everyone who helped with this release candidate, either by
>>> contributing code, testing, or documentation.
>>>
>>> Regards,
>>> Colin
>>>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.9 #93

[Apache Jenkins Server]

See