Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2649

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-939: Support Participation in 2PC

[Artem Livshits]

Hi Jun,

Thank you for your questions.

> 20. So to abort a prepared transaction after the producer start, we could
use ...

I agree, initTransaction(true) + abort would accomplish the behavior of
initTransactions(false), so we could technically have fewer ways to achieve
the same thing, which is generally valuable.  I wonder, though, if that
would be intuitive from the application perspective.  Say if an application
currently uses initTransactions() to achieve the current semantics, it
would need to be rewritten to use initTransactions() + abort to achieve the
same semantics if the config is changed.  I think this could create
subtle confusion, as the config change is generally decoupled from changing
application implementation.

>  The use case mentioned for keepPreparedTxn=true without 2PC doesn't seem
very important

I agree, it's not a strict requirement.  It is, however, a missing option
in the public API, so currently Flink has to use reflection to emulate this
functionality without 2PC support.   Even when KIP-939 is implemented,
there would be situations when 2PC is disabled by the admin (e.g. Kafka
service providers may be reluctant to enable 2PC for Flink services that
users host themselves), so we either have to perpetuate the
reflection-based implementation in Flink or enable keepPreparedTxn=true
without 2PC.

> 32.
kafka.server:type=transaction-coordinator-metrics,name=active-transaction-open-time-max

I just followed the existing metric implementation example
https://github.com/apache/kafka/blob/trunk/core/src/main/scala/kafka/coordinator/transaction/TransactionStateManager.scala#L95,
which maps to
kafka.server:type=transaction-coordinator-metrics,name=partition-load-time-max.

> 33. "If the value is 'true' then the corresponding field is set

That's correct.  Updated the KIP.

-Artem

On Wed, Feb 7, 2024 at 10:06 AM Jun Rao  wrote:

> Hi, Artem,
>
> Thanks for the reply.
>
> 20. So to abort a prepared transaction after producer start, we could use
> either
>   producer.initTransactions(false)
> or
>   producer.initTransactions(true)
>   producer.abortTransaction
> Could we just always use the latter API? If we do this, we could
> potentially eliminate the keepPreparedTxn flag in initTransactions(). After
> the initTransactions() call, the outstanding txn is always preserved if 2pc
> is enabled and aborted if 2pc is disabled. The use case mentioned for
> keepPreparedTxn=true without 2PC doesn't seem very important. If we could
> do that, it seems that we have (1) less redundant and simpler APIs; (2)
> more symmetric syntax for aborting/committing a prepared txn after producer
> restart.
>
> 32.
>
> kafka.server:type=transaction-coordinator-metrics,name=active-transaction-open-time-max
> Is this a Yammer or kafka metric? The former uses the camel case for name
> and type. The latter uses the hyphen notation, but doesn't have the type
> attribute.
>
> 33. "If the value is 'true' then the corresponding field is set in the
> InitProducerIdRequest and the KafkaProducer object is set into a state
> which only allows calling .commitTransaction or .abortTransaction."
> We should also allow .completeTransaction, right?
>
> Jun
>
>
> On Tue, Feb 6, 2024 at 3:29 PM Artem Livshits
>  wrote:
>
> > Hi Jun,
> >
> > > 20. For Flink usage, it seems that the APIs used to abort and commit a
> > prepared txn are not symmetric.
> >
> > For Flink it is expected that Flink would call .commitTransaction or
> > .abortTransaction directly, it wouldn't need to deal with
> PreparedTxnState,
> > the outcome is actually determined by the Flink's job manager, not by
> > comparison of PreparedTxnState.  So for Flink, if the Kafka sync crashes
> > and restarts there are 2 cases:
> >
> > 1. Transaction is not prepared.  In that case just call
> > producer.initTransactions(false) and then can start transactions as
> needed.
> > 2. Transaction is prepared.  In that case call
> > producer.initTransactions(true) and wait for the decision from the job
> > manager.  Note that it's not given that the transaction will get
> committed,
> > the decision could also be an abort.
> >
> >  > 21. transaction.max.timeout.ms could in theory be MAX_INT. Perhaps we
> > could use a negative timeout in the record to indicate 2PC?
> >
> > -1 sounds good, updated.
> >
> > > 30. The KIP has two different APIs to abort an ongoing txn. Do we need
> > both?
> >
> > I think of producer.initTransactions() to be an implementation for
> > adminClient.forceTerminateTransaction(transactionalId).
> >
> > > 31. "This would flush all the pending messages and transition the
> > producer
> >
> > Updated the KIP to clarify that IllegalStateException will be thrown.
> >
> > -Artem
> >
> >
> > On Mon, Feb 5, 2024 at 2:22 PM Jun Rao  wrote:
> >
> > > Hi, Artem,
> > >
> > > Thanks for the reply.
> > >
> > > 20. For Flink usage, it seems that the APIs used to abort and commit a
> > > prepared txn are not symmetric.
> > > To abort, the app will just call
> > >   

[jira] [Created] (KAFKA-16263) Add Kafka Streams docs about available listeners/callback

[Matthias J. Sax (Jira)]

Matthias J. Sax created KAFKA-16263:
---

 Summary: Add Kafka Streams docs about available listeners/callback
 Key: KAFKA-16263
 URL: https://issues.apache.org/jira/browse/KAFKA-16263
 Project: Kafka
  Issue Type: Task
  Components: docs, streams
Reporter: Matthias J. Sax


Kafka Streams allows to register all kind of listeners and callback (eg, 
uncaught-exception-handler, restore-listeners, etc) but those are not in the 
documentation.

A good place might be 
[https://kafka.apache.org/documentation/streams/developer-guide/running-app.html]
 



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

[jira] [Created] (KAFKA-16262) Add IQv2 to Kafka Streams documentation

[Matthias J. Sax (Jira)]

Matthias J. Sax created KAFKA-16262:
---

 Summary: Add IQv2 to Kafka Streams documentation
 Key: KAFKA-16262
 URL: https://issues.apache.org/jira/browse/KAFKA-16262
 Project: Kafka
  Issue Type: Task
  Components: docs, streams
Reporter: Matthias J. Sax


The new IQv2 API was added many release ago. While it is still not feature 
complete, we should add it to the docs 
([https://kafka.apache.org/documentation/streams/developer-guide/interactive-queries.html])
 to make users aware of the new API so they can start to try it out, report 
issue and provide feedback / feature requests.

We might still state that IQv2 is not yet feature complete, but should change 
the docs in a way to position is as the "new API", and have code exmples.



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

[jira] [Resolved] (KAFKA-16259) Immutable MetadataCache to improve client performance

[Zhifeng Chen (Jira)]

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

Zhifeng Chen resolved KAFKA-16259.
--
Resolution: Duplicate

> Immutable MetadataCache to improve client performance
> -
>
> Key: KAFKA-16259
> URL: https://issues.apache.org/jira/browse/KAFKA-16259
> Project: Kafka
>  Issue Type: Improvement
>  Components: clients
>Affects Versions: 2.8.0
>Reporter: Zhifeng Chen
>Assignee: Zhifeng Chen
>Priority: Major
> Attachments: image-2024-02-14-12-11-07-366.png
>
>
> TL;DR, A Kafka client produce latency issue is identified caused by 
> synchronized lock contention of metadata cache read/write in the native kafka 
> producer.
> Trigger Condition: A producer need to produce to large number of topics. such 
> as in kafka rest-proxy
>  
>  
> What is producer metadata cache
> Kafka producer maintains a in-memory copy of cluster metadata, and it avoided 
> fetch metadata every time when produce message to reduce latency
>  
> What’s the synchronized lock contention problem
> Kafka producer metadata cache is a *mutable* object, read/write are isolated 
> by a synchronized lock. Which means when the metadata cache is being updated, 
> all read requests are blocked. 
> Topic metadata expiration frequency increase liner with number of topics. In 
> a kafka cluster with large number of topic partitions, topic metadata 
> expiration and refresh triggers high frequent metadata update. When read 
> operation blocked by update, producer threads are blocked and caused high 
> produce latency issue.
>  
> *Proposed solution*
> TL;DR Optimize performance of metadata cache read operation of native kafka 
> producer with copy-on-write strategy
> What is copy-on-write strategy
> It’s a solution to reduce synchronized lock contention by making the object 
> immutable, and always create a new instance when updating, but since the 
> object is immutable, read operation will be free from waiting, thus produce 
> latency reduced significantly
> Besides performance, it can also make the metadata cache immutable from 
> unexpected modification, reduce occurrence of code bugs due to incorrect 
> synchronization 
>  
> {*}Test result{*}:
> Environment: Kafka-rest-proxy
> Client version: 2.8.0
> Number of topic partitions: 250k
> test result show 90%+ latency reduction on test cluster
> !image-2024-02-14-12-11-07-366.png!
> P99 produce latency on deployed instances reduced from 200ms -> 5ms (upper 
> part show latency after the improvement, lower part show before improvement)
> *Dump show details of the problem*
> Threads acquiring lock
>  Kafka-rest-proxy-jetty-thread-pool-199waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-200waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-202waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-203waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-204waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-205waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-207waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-212waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-214waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-215waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-217waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-218waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-219waiting to acquire [ 
> 0x7f77d70121a0 ]
>  Kafka-rest-proxy-jetty-thread-pool-222waiting to acquire [ 
> 0x7f77d70121a0 ]
>  ...
> at org.apache.kafka.clients.Metadata.fetch(Metadata.java:111)
> at 
> org.apache.kafka.clients.producer.KafkaProducer.waitOnMetadata(KafkaProducer.java:1019)
> at 
> org.apache.kafka.clients.producer.KafkaProducer.partitionsFor(KafkaProducer.java:1144)
> at 
> io.confluent.kafkarest.producer.internal.MetadataImpl.maybeUpdate(MetadataImpl.java:39)
> at 
> io.confluent.kafkarest.producer.ResilientProducer.send(ResilientProducer.java:117)
> Threads hold the lock
>  kafka-producer-network-thread | kafka-rest-proxyrunning , holding [ 
> 0x7f77d70121a0 ]
> at 
> java.util.stream.ReferencePipeline$3$1.accept(java.base@11.0.18/ReferencePipeline.java:195)
> at 
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(java.base@11.0.18/ArrayList.java:1655)
> at 
> java.util.stream.AbstractPipeline.copyInto(java.base@11.0.18/AbstractPipeline.java:484)
> at 
> org.apache.kafka.common.requests.MetadataResponse.convertToNodeArray(MetadataResponse.java:162)
> 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2648

[Apache Jenkins Server]

See 

[jira] [Created] (KAFKA-16261) MembershipManagerImpl.updateSubscription fails if already empty subscription

[Andrew Schofield (Jira)]

Andrew Schofield created KAFKA-16261:


 Summary: MembershipManagerImpl.updateSubscription fails if already 
empty subscription
 Key: KAFKA-16261
 URL: https://issues.apache.org/jira/browse/KAFKA-16261
 Project: Kafka
  Issue Type: Bug
  Components: clients
Reporter: Andrew Schofield
Assignee: Lianet Magrans


The internal SubscriptionState object keeps track of whether the assignment is 
user-assigned, or auto-assigned. If there are no assigned partitions, the 
assignment resets to NONE. If you call SubscriptionState.assignFromSubscribed 
in this state it fails.

The easiest thing is perhaps to check 
SubscriptionState.hasAutoAssignedPartitions() to make sure that 
assignFromSubscribed is going to be permitted.



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

Re: [VOTE] 3.7.0 RC4

[Mickael Maison]

Hi Stanislav,

Thanks for running the release.

I did the following testing:
- verified the check sums and signatures
- ran ZooKeeper and KRaft quickstarts with Scala 2.13 binaries
- ran a successful migration from ZooKeeper to KRaft

We seem to be missing the upgrade notes for 3.7.0 in the docs. See
https://kafka.apache.org/37/documentation.html#upgrade that still
points to 3.6.0
Before voting I'd like to see results from the system tests too.

Thanks,
Mickael

On Thu, Feb 15, 2024 at 6:06 PM Andrew Schofield
 wrote:
>
> +1 (non-binding). I used the staged binaries with Scala 2.13. I tried the new 
> group coordinator
> and consumer group protocol which is included with the Early Access release 
> of KIP-848.
> Also verified the availability of the new APIs. All working as expected.
>
> Thanks,
> Andrew
>
> > On 15 Feb 2024, at 05:07, Paolo Patierno  wrote:
> >
> > +1 (non-binding). I used the staged binaries with Scala 2.13 and mostly
> > focused on the ZooKeeper to KRaft migration with multiple tests. Everything
> > works fine.
> >
> > Thanks
> > Paolo
> >
> > On Mon, 12 Feb 2024, 22:06 Jakub Scholz,  wrote:
> >
> >> +1 (non-binding). I used the staged binaries with Scala 2.13 and the staged
> >> Maven artifacts to run my tests. All seems to work fine. Thanks.
> >>
> >> Jakub
> >>
> >> On Fri, Feb 9, 2024 at 4:20 PM Stanislav Kozlovski
> >>  wrote:
> >>
> >>> Hello Kafka users, developers and client-developers,
> >>>
> >>> This is the second candidate we are considering for release of Apache
> >> Kafka
> >>> 3.7.0.
> >>>
> >>> Major changes include:
> >>> - Early Access to KIP-848 - the next generation of the consumer rebalance
> >>> protocol
> >>> - Early Access to KIP-858: Adding JBOD support to KRaft
> >>> - KIP-714: Observability into Client metrics via a standardized interface
> >>>
> >>> Release notes for the 3.7.0 release:
> >>>
> >>>
> >> https://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/RELEASE_NOTES.html
> >>>
> >>> *** Please download, test and vote by Thursday, February 15th, 9AM PST
> >> ***
> >>>
> >>> 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://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/
> >>>
> >>> * Docker release artifact to be voted upon:
> >>> apache/kafka:3.7.0-rc4
> >>>
> >>> * Maven artifacts to be voted upon:
> >>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
> >>>
> >>> * Javadoc:
> >>> https://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/javadoc/
> >>>
> >>> * Tag to be voted upon (off 3.7 branch) is the 3.7.0 tag:
> >>> https://github.com/apache/kafka/releases/tag/3.7.0-rc4
> >>>
> >>> * Documentation:
> >>> https://kafka.apache.org/37/documentation.html
> >>>
> >>> * Protocol:
> >>> https://kafka.apache.org/37/protocol.html
> >>>
> >>> * Successful Jenkins builds for the 3.7 branch:
> >>>
> >>> Unit/integration tests: I am in the process of running and analyzing
> >> these.
> >>> System tests: I am in the process of running these.
> >>>
> >>> Expect a follow-up over the weekend
> >>>
> >>> * Successful Docker Image Github Actions Pipeline for 3.7 branch:
> >>> Docker Build Test Pipeline:
> >>> https://github.com/apache/kafka/actions/runs/7845614846
> >>>
> >>> /**
> >>>
> >>> Best,
> >>> Stanislav
> >>>
> >>
>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2647

[Apache Jenkins Server]

See 

Re: [DISCUSS] Kafka-Streams-Scala for Scala 3

[Matthias Berndt]

Htey there,

I'd like to raise this topic again because I haven't yet gotten anything
actionable here and I want to make a Scala 3 release of Kafka-Streams-Scala
happen sooner rather than later.

All the best,
Matthias

Am Di., 13. Feb. 2024 um 12:48 Uhr schrieb Matthias Berndt <
matthias.ber...@ttmzero.com>:

> Hey Matthew,
>
> Kafka-Streams-Scala is an entirely separate codebase from Kafka Core, and
> the fact that almost three years after the release of Scala 3 there is
> still no release of Kafka-Streams-Scala for Scala 3 – even though the
> required changes to the codebase are trivial – tells me that these things
> should not be coupled in the way that they currently are. I think having
> Kafka-Streams-Scala users wait for Kafka 4 would be doing them a
> disservice. Are we really going to delay this because of some CI scripts?
>
> All the best
> Matthias
>
> Am Di., 13. Feb. 2024 um 11:20 Uhr schrieb Matthew de Detrich
> :
>
>> As added info on top of what Josep said, in the Scala space most OS
>> software supports
>> Scala 2.12/Scala 2.13 and Scala 3 but with Scala 2.12 specifically the
>> Scala OS
>> community itself wants to eventually have people to stop supporting it
>> (it's in maintenance mode) so it makes sense to tie this into Kafka 4.0.x
>> which will
>> drop Scala 2.12 support.
>>
>> We should also take care and make sure the Scala 3 version is pinned to
>> 3.3.x since
>> it's part of the LTS[1] series, in other words we should be careful that
>> people won't bump
>> the Scala version to 3.4.x.
>>
>> 1:
>>
>> https://www.scala-lang.org/blog/2022/08/17/long-term-compatibility-plans.html
>>
>> On Sat, Feb 10, 2024 at 11:54 AM Matthias Berndt <
>> matthias.ber...@ttmzero.com> wrote:
>>
>> > Hey there,
>> >
>> > I'd like to discuss a Scala 3 release of the Kafka-Streams-Scala
>> library.
>> > As you might have seen already, I have recently created a ticket
>> > https://issues.apache.org/jira/browse/KAFKA-16237
>> > and a PR
>> > https://github.com/apache/kafka/pull/15338
>> > to move this forward. The changes required to make Kafka-Streams-Scala
>> > compile with Scala 3 are trivial; the trickier part is the build system
>> and
>> > the release process
>> > I have made some changes to the build system (feel free to comment on
>> the
>> > above PR about that) that make it possible to test Kafka-Streams-Scala
>> and
>> > build the jar. What remains to be done is the CI and release process.
>> There
>> > is a `release.py` file in the Kafka repository's root directory, which
>> > assumes that all artifacts are available for all supported Scala
>> versions.
>> > This is no longer the case with my changes because while porting
>> > Kafka-Streams-Scala to Scala 3 is trivial, porting Kafka to Scala 3 is
>> less
>> > so, and shouldn't hold back a Scala 3 release of Kafka-Streams-Scala. I
>> > would appreciate some guidance as to what the release process should
>> look
>> > like in the future.
>> >
>> > Oh and I've made a PR to remove a syntax error from release.py.
>> > https://github.com/apache/kafka/pull/15350
>> >
>> > All the best,
>> > Matthias
>> >
>>
>>
>> --
>>
>> Matthew de Detrich
>>
>> *Aiven Deutschland GmbH*
>>
>> Immanuelkirchstraße 26, 10405 Berlin
>>
>> Alexanderufer 3-7, 10117 Berlin
>>
>> Amtsgericht Charlottenburg, HRB 209739 B
>>
>> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>>
>> *m:* +491603708037
>>
>> *w:* aiven.io *e:* matthew.dedetr...@aiven.io
>>
>

Re: [Discuss] KIP-1019: Expose method to determine Metric Measurability

[Manikumar]

LGTM, Thanks for the KIP.

On Thu, Feb 15, 2024 at 8:50 PM Doğuşcan Namal 
wrote:

> LGTM thanks for the KIP.
>
> +1(non-binding)
>
> On Wed, 14 Feb 2024 at 15:22, Andrew Schofield <
> andrew_schofield_j...@outlook.com> wrote:
>
> > Hi Apoorv,
> > Thanks for the KIP. Looks like a useful change to tidy up the metrics
> code.
> >
> > Thanks,
> > Andrew
> >
> > > On 14 Feb 2024, at 14:55, Apoorv Mittal 
> > wrote:
> > >
> > > Hi,
> > > I would like to start discussion of a small KIP which fills a gap in
> > > determining Kafka Metric measurability.
> > >
> > > KIP-1019: Expose method to determine Metric Measurability
> > > <
> >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1019%3A+Expose+method+to+determine+Metric+Measurability
> > >
> > >
> > > Regards,
> > > Apoorv Mittal
> >
> >
>

Re: [Discuss] KIP-1019: Expose method to determine Metric Measurability

[Doğuşcan Namal]

LGTM thanks for the KIP.

+1(non-binding)

On Wed, 14 Feb 2024 at 15:22, Andrew Schofield <
andrew_schofield_j...@outlook.com> wrote:

> Hi Apoorv,
> Thanks for the KIP. Looks like a useful change to tidy up the metrics code.
>
> Thanks,
> Andrew
>
> > On 14 Feb 2024, at 14:55, Apoorv Mittal 
> wrote:
> >
> > Hi,
> > I would like to start discussion of a small KIP which fills a gap in
> > determining Kafka Metric measurability.
> >
> > KIP-1019: Expose method to determine Metric Measurability
> > <
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1019%3A+Expose+method+to+determine+Metric+Measurability
> >
> >
> > Regards,
> > Apoorv Mittal
>
>

Re: [VOTE] 3.7.0 RC4

[Andrew Schofield]

+1 (non-binding). I used the staged binaries with Scala 2.13. I tried the new 
group coordinator
and consumer group protocol which is included with the Early Access release of 
KIP-848.
Also verified the availability of the new APIs. All working as expected.

Thanks,
Andrew

> On 15 Feb 2024, at 05:07, Paolo Patierno  wrote:
>
> +1 (non-binding). I used the staged binaries with Scala 2.13 and mostly
> focused on the ZooKeeper to KRaft migration with multiple tests. Everything
> works fine.
>
> Thanks
> Paolo
>
> On Mon, 12 Feb 2024, 22:06 Jakub Scholz,  wrote:
>
>> +1 (non-binding). I used the staged binaries with Scala 2.13 and the staged
>> Maven artifacts to run my tests. All seems to work fine. Thanks.
>>
>> Jakub
>>
>> On Fri, Feb 9, 2024 at 4:20 PM Stanislav Kozlovski
>>  wrote:
>>
>>> Hello Kafka users, developers and client-developers,
>>>
>>> This is the second candidate we are considering for release of Apache
>> Kafka
>>> 3.7.0.
>>>
>>> Major changes include:
>>> - Early Access to KIP-848 - the next generation of the consumer rebalance
>>> protocol
>>> - Early Access to KIP-858: Adding JBOD support to KRaft
>>> - KIP-714: Observability into Client metrics via a standardized interface
>>>
>>> Release notes for the 3.7.0 release:
>>>
>>>
>> https://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/RELEASE_NOTES.html
>>>
>>> *** Please download, test and vote by Thursday, February 15th, 9AM PST
>> ***
>>>
>>> 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://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/
>>>
>>> * Docker release artifact to be voted upon:
>>> apache/kafka:3.7.0-rc4
>>>
>>> * Maven artifacts to be voted upon:
>>> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>>>
>>> * Javadoc:
>>> https://home.apache.org/~stanislavkozlovski/kafka-3.7.0-rc4/javadoc/
>>>
>>> * Tag to be voted upon (off 3.7 branch) is the 3.7.0 tag:
>>> https://github.com/apache/kafka/releases/tag/3.7.0-rc4
>>>
>>> * Documentation:
>>> https://kafka.apache.org/37/documentation.html
>>>
>>> * Protocol:
>>> https://kafka.apache.org/37/protocol.html
>>>
>>> * Successful Jenkins builds for the 3.7 branch:
>>>
>>> Unit/integration tests: I am in the process of running and analyzing
>> these.
>>> System tests: I am in the process of running these.
>>>
>>> Expect a follow-up over the weekend
>>>
>>> * Successful Docker Image Github Actions Pipeline for 3.7 branch:
>>> Docker Build Test Pipeline:
>>> https://github.com/apache/kafka/actions/runs/7845614846
>>>
>>> /**
>>>
>>> Best,
>>> Stanislav
>>>
>>

[DISCUSS] KIP-1020: Deprecate `window.size.ms` in `StreamsConfig`

[Lucia Cerchie]

Hey everyone,

I'd like to discuss KIP-1020
,
which would move to deprecate `window.size.ms` in `StreamsConfig` since `
window.size.ms` is a client config.

Thanks in advance!

Lucia Cerchie

Jenkins build is still unstable: Kafka » Kafka Branch Builder » trunk #2646

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-967: Support custom SSL configuration for Kafka Connect RestServer

[Taras Ledkov]

Hi team,

Excuse me for duplicate. The last message isn't attached to the thread. I try 
to fix it by this email.

Ping for review / vote for KIP-967 [1].
Voting thread is here [2]

Please pay your attention, I beg of you.
I'm a little frustrated by the lack of community interest in what
seems like a simple and necessary patch.
Is the SslEngineFactory refactoring requirement blocking?

[1]. 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-967%3A+Support+custom+SSL+configuration+for+Kafka+Connect+RestServer
[2]. https://lists.apache.org/thread/wc4v5v3pynl15g1q547m2croqsqgmzpw

Re: [DISCUSS] KIP-967: Support custom SSL configuration for Kafka Connect RestServer

[Taras Ledkov]

Hi team,

Ping for review / vote for KIP-967 [1].
Voting thread is here [2]

Please pay your attention, I beg of you.
I'm a little frustrated by the lack of community interest in what
seems like a simple and necessary patch.
Is the SslEngineFactory refactoring requirement blocking?

[1]. 
https://cwiki.apache.org/confluence/display/KAFKA/KIP-967%3A+Support+custom+SSL+configuration+for+Kafka+Connect+RestServer
[2]. https://lists.apache.org/thread/wc4v5v3pynl15g1q547m2croqsqgmzpw
--
With best regards,
Taras Ledkov