Re: [DISCUSS] Apache Kafka 3.4.0 release

[Sophie Blee-Goldman]

Hey everyone,

Rejoice (or not) for we are now past code freeze for the 3.4 release! This
means you
should not be merging any new code to the 3.4 branch unless/until it's been
approved
as a blocker. For now feel free to also merge things like flaky test fixes
and docs PRs
that don't touch any non-testing code -- consider those automatically
approved (though
it never hurts to ping me for a heads up).

I'll be going through the list of unresolved tickets that are still marked
for 3.4 and will
bump anything that's not already approved or a flaky test ticket out to
3.5. So please
take a moment to go through any open 3.4 tickets that belong to you. This
page 
provides a useful view for what's still out there.

As always let me know if you have any questions and make sure to raise any
potential
blockers here for approval.

Devij: thanks for the offer to help reenable the ARM build, but it was only
disabled for
tooling reasons (often failed due to lack of available nodes). I guess when
we can
finally drop support for Java 8 then we can use those nodes for the ARM
build.
Until then, rest assured I will still validate the 3.4 release on ARM

Sophie

On Fri, Dec 9, 2022 at 9:12 AM Divij Vaidya  wrote:

> Hey Sophie
>
> I was wondering whether we should try to get the ARM build working again so
> that we can perform release qualification of 3.4.x on ARM as well (which
> was disabled in https://github.com/apache/kafka/pull/12380)? I would be
> happy to pick up the work if someone can point me to the history on this
> subject.
>
> --
> Divij Vaidya
>
>
>
> On Thu, Dec 8, 2022 at 3:48 AM Sophie Blee-Goldman
>  wrote:
>
> > Thanks everyone for the updates, that all sounds good.
> >
> > Divij: I pinged some of the relevant reviewers to give your PRs a final
> > pass, but will
> > leave it to their judgement from here as I'm not familiar with either.
> >
> > Everyone else: reminder that today is the official code freeze deadline,
> so
> > please try
> > and get your PRs in by EOD! If you have something on the edge and worry
> > it's not
> > ready, feel free to reach out for an extension: I'd rather give you an
> > extra day or two
> > than risk finding a blocker weeks from now because a PR was rushed :)
> >
> > On Wed, Dec 7, 2022 at 2:04 PM Chris Egerton 
> > wrote:
> >
> > > Hi Sophie,
> > >
> > > Thanks for taking a look at the MM2 issue. We've merged a
> > > (minimally-scoped) fix and backported it to the 3.4 branch; the issue
> > > should be resolved now.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> > > On Wed, Dec 7, 2022 at 3:12 PM Rajini Sivaram  >
> > > wrote:
> > >
> > > > Hi Sophie,
> > > >
> > > > I have merged PR #12954 for KIP-881 to 3.4 branch. Please let me know
> > if
> > > > that is ok.
> > > >
> > > > Thank you,
> > > >
> > > > Rajini
> > > >
> > > >
> > > > On Wed, Dec 7, 2022 at 11:43 AM Rajini Sivaram <
> > rajinisiva...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi Sophie,
> > > > >
> > > > > The first PR for KIP-881 which contains protocol changes has been
> > > merged
> > > > > to trunk (https://github.com/apache/kafka/pull/12954). It is a
> > > > relatively
> > > > > small PR, can we merge to 3.4.0?
> > > > >
> > > > > Thank you,
> > > > >
> > > > > Rajini
> > > > >
> > > > >
> > > > > On Wed, Dec 7, 2022 at 11:16 AM Divij Vaidya <
> > divijvaidy...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> Hey Sophie
> > > > >>
> > > > >> I have a couple of pending PRs which have been waiting for review
> > > since
> > > > >> preparation of the 3.3 release. They are not blockers for 3.4 but
> > are
> > > > >> being
> > > > >> tracked as improvements that we would like to add to 3.4 release.
> > > > >>
> > > > >> Please consider taking a look when you get a chance:
> > > > >>
> > > > >> 1. https://issues.apache.org/jira/browse/KAFKA-7109
> > > > >> 2. https://github.com/apache/kafka/pull/12228
> > > > >>
> > > > >> --
> > > > >> Divij Vaidya
> > > > >>
> > > > >>
> > > > >>
> > > > >> On Wed, Dec 7, 2022 at 3:18 AM Sophie Blee-Goldman
> > > > >>  wrote:
> > > > >>
> > > > >> > Hey all,
> > > > >> >
> > > > >> > First off, just a heads up that code freeze will be *tomorrow,
> Dec
> > > > 6th*
> > > > >> so
> > > > >> > please make sure
> > > > >> > to merge any lingering PRs by EOD Wednesday (PST). If you have a
> > > > >> potential
> > > > >> > blocker
> > > > >> > that may take longer to fix and hasn't already been communicated
> > to
> > > > me,
> > > > >> > please reach out
> > > > >> > to me now and make sure the ticket is marked as a blocker for
> 3.4
> > > > >> >
> > > > >> > Also note that the 3.4 branch has been created, so going forward
> > > > you'll
> > > > >> > need to ensure that
> > > > >> > newly merged PRs are cherrypicked to this branch to make the 3.4
> > > > >> release.
> > > > >> >
> > > > >> > Thanks, and don't hesitate to reach out if you have any
> questions.
> > > > >> >
> > > > >> > Greg/Chris -- I looked over the 

Jenkins build is unstable: Kafka » Kafka Branch Builder » trunk #1423

[Apache Jenkins Server]

See 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.4 #7

[Apache Jenkins Server]

See 

[jira] [Resolved] (KAFKA-14286) Time based cluster metadata snapshots

[Jira]

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

José Armando García Sancio resolved KAFKA-14286.

Resolution: Fixed

> Time based cluster metadata snapshots
> -
>
> Key: KAFKA-14286
> URL: https://issues.apache.org/jira/browse/KAFKA-14286
> Project: Kafka
>  Issue Type: New Feature
>Reporter: José Armando García Sancio
>Assignee: José Armando García Sancio
>Priority: Major
> Fix For: 3.4.0
>
>
> KIP: https://cwiki.apache.org/confluence/x/MY3GDQ



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

[jira] [Created] (KAFKA-14460) In-memory store iterators can return results with null values

[A. Sophie Blee-Goldman (Jira)]

A. Sophie Blee-Goldman created KAFKA-14460:
--

 Summary: In-memory store iterators can return results with null 
values
 Key: KAFKA-14460
 URL: https://issues.apache.org/jira/browse/KAFKA-14460
 Project: Kafka
  Issue Type: Bug
  Components: streams
Reporter: A. Sophie Blee-Goldman


Due to the thread-safety model we adopted in our in-memory stores to avoid 
scaling issues, we synchronize all read/write methods and then during range 
scans, copy the keyset of all results rather than returning a direct iterator 
over the underlying map. When users call #next to read out the iterator 
results, we issue a point lookup on the next key and then simply return a new 
KeyValue<>(key, get(key))

This lets the range scan return results without blocking access to the store by 
other threads and without risk of ConcurrentModification, as a writer can 
modify the real store without affecting the keyset copy of the iterator. This 
also means that those changes won't be reflected in what the iterator sees or 
returns, which in itself is fine as we don't guarantee consistency semantics of 
any kind.

However, we _do_ guarantee that range scans "must not return null values" – and 
this contract may be violated if the StreamThread deletes a record that the 
iterator was going to return.

tl;dr we should check get(key) for null and skip to the next result if 
necessary in the in-memory store iterators. See for example 
InMemoryKeyValueIterator (note that we'll probably need to buffer one record in 
advance before we return true from #hasNext)



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

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1422

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 434216 lines...]
[2022-12-10T02:58:51.534Z] > Task :connect:json:testJar
[2022-12-10T02:58:51.534Z] > Task :connect:json:testSrcJar
[2022-12-10T02:58:52.711Z] > Task :metadata:compileTestJava UP-TO-DATE
[2022-12-10T02:58:52.711Z] > Task :metadata:testClasses UP-TO-DATE
[2022-12-10T02:58:52.711Z] > Task 
:clients:generateMetadataFileForMavenJavaPublication
[2022-12-10T02:58:52.711Z] > Task 
:clients:generatePomFileForMavenJavaPublication
[2022-12-10T02:58:52.711Z] 
[2022-12-10T02:58:52.711Z] > Task :streams:processMessages
[2022-12-10T02:58:52.711Z] Execution optimizations have been disabled for task 
':streams:processMessages' to ensure correctness due to the following reasons:
[2022-12-10T02:58:52.711Z]   - Gradle detected a problem with the following 
location: 
'/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/generated/java/org/apache/kafka/streams/internals/generated'.
 Reason: Task ':streams:srcJar' uses this output of task 
':streams:processMessages' without declaring an explicit or implicit 
dependency. This can lead to incorrect results being produced, depending on 
what order the tasks are executed. Please refer to 
https://docs.gradle.org/7.6/userguide/validation_problems.html#implicit_dependency
 for more details about this problem.
[2022-12-10T02:58:52.711Z] MessageGenerator: processed 1 Kafka message JSON 
files(s).
[2022-12-10T02:58:52.711Z] 
[2022-12-10T02:58:52.711Z] > Task :streams:compileJava UP-TO-DATE
[2022-12-10T02:58:52.711Z] > Task :streams:classes UP-TO-DATE
[2022-12-10T02:58:52.711Z] > Task :streams:test-utils:compileJava UP-TO-DATE
[2022-12-10T02:58:53.886Z] > Task :streams:copyDependantLibs
[2022-12-10T02:58:53.886Z] > Task :streams:jar UP-TO-DATE
[2022-12-10T02:58:53.886Z] > Task 
:streams:generateMetadataFileForMavenJavaPublication
[2022-12-10T02:58:57.239Z] > Task :connect:api:javadoc
[2022-12-10T02:58:57.239Z] > Task :connect:api:copyDependantLibs UP-TO-DATE
[2022-12-10T02:58:57.239Z] > Task :connect:api:jar UP-TO-DATE
[2022-12-10T02:58:57.239Z] > Task 
:connect:api:generateMetadataFileForMavenJavaPublication
[2022-12-10T02:58:57.239Z] > Task :connect:json:copyDependantLibs UP-TO-DATE
[2022-12-10T02:58:57.239Z] > Task :connect:json:jar UP-TO-DATE
[2022-12-10T02:58:57.239Z] > Task 
:connect:json:generateMetadataFileForMavenJavaPublication
[2022-12-10T02:58:57.239Z] > Task 
:connect:json:publishMavenJavaPublicationToMavenLocal
[2022-12-10T02:58:57.239Z] > Task :connect:json:publishToMavenLocal
[2022-12-10T02:58:57.239Z] > Task :connect:api:javadocJar
[2022-12-10T02:58:58.247Z] > Task :connect:api:compileTestJava UP-TO-DATE
[2022-12-10T02:58:58.247Z] > Task :connect:api:testClasses UP-TO-DATE
[2022-12-10T02:58:58.247Z] > Task :connect:api:testJar
[2022-12-10T02:58:58.247Z] > Task :connect:api:testSrcJar
[2022-12-10T02:58:58.247Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2022-12-10T02:58:58.247Z] > Task :connect:api:publishToMavenLocal
[2022-12-10T02:58:58.247Z] 
[2022-12-10T02:58:58.247Z] > Task :streams:javadoc
[2022-12-10T02:58:58.247Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/processor/StreamPartitioner.java:54:
 warning - Tag @link: reference not found: 
org.apache.kafka.clients.producer.internals.DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:854:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-10T02:58:59.478Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: 

[jira] [Created] (KAFKA-14459) Document how to use and close a 'Statistics' in the example RocksDBConfigSetter

[A. Sophie Blee-Goldman (Jira)]

A. Sophie Blee-Goldman created KAFKA-14459:
--

 Summary: Document how to use and close a 'Statistics' in the 
example RocksDBConfigSetter
 Key: KAFKA-14459
 URL: https://issues.apache.org/jira/browse/KAFKA-14459
 Project: Kafka
  Issue Type: Improvement
  Components: docs, streams
Reporter: A. Sophie Blee-Goldman


We fixed a memory leak in KAFKA-14432 where we were sometimes failing to close 
the `Statistics` object used for rocksdb metrics. Since users can define their 
own Statistics as well, we should make sure they know that this has to be 
closed like we do for other `RocksDBObject` classes like the Cache. It might 
also be useful to provide an example of how to use Statistics and what can be 
done with it.

 

We currently have two sample RocksDBConfigSetter implementations in the docs, 
both of which could be updated here:
 # [rocksdb memory management 
docs](https://kafka.apache.org/documentation/streams/developer-guide/memory-mgmt.html#rocksdb)
 -- consider including a Statistics in this example to highlight that it needs 
to be closed? This one could arguably be skipped, although the formatting of 
this sample config setter seems to be messed up so this might be a good 
opportunity to fix that on the side
 # [rocksdb.config.setter config 
docs](https://kafka.apache.org/documentation/streams/developer-guide/config-streams.html#id20):
 this would be a good place to include an example that actually uses the 
Statistics for something (assuming there's some reason for users to define 
their own Statistics in the first place, which I personally do not know). We 
can potentially link to this example from the metrics docs



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

[jira] [Resolved] (KAFKA-14454) KTableKTableForeignKeyInnerJoinCustomPartitionerIntegrationTest#shouldThrowIllegalArgumentExceptionWhenCustomPartionerReturnsMultiplePartitions passes when run individu

[A. Sophie Blee-Goldman (Jira)]

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

A. Sophie Blee-Goldman resolved KAFKA-14454.

Resolution: Fixed

> KTableKTableForeignKeyInnerJoinCustomPartitionerIntegrationTest#shouldThrowIllegalArgumentExceptionWhenCustomPartionerReturnsMultiplePartitions
>  passes when run individually but not when is run as part of the IT
> --
>
> Key: KAFKA-14454
> URL: https://issues.apache.org/jira/browse/KAFKA-14454
> Project: Kafka
>  Issue Type: Bug
>Reporter: Sagar Rao
>Assignee: Sagar Rao
>Priority: Major
>
> Newly added test 
> KTableKTableForeignKeyInnerJoinCustomPartitionerIntegrationTest#shouldThrowIllegalArgumentExceptionWhenCustomPartionerReturnsMultiplePartitions
>  as part of KIP-837 passes when run individually but fails when is part of IT 
> class and hence is marked as Ignored. 
>  



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

[jira] [Created] (KAFKA-14458) RPC Handler to ZkBrokers from KRaft Controller

[Akhilesh Chaganti (Jira)]

Akhilesh Chaganti created KAFKA-14458:
-

 Summary: RPC Handler to ZkBrokers from KRaft Controller
 Key: KAFKA-14458
 URL: https://issues.apache.org/jira/browse/KAFKA-14458
 Project: Kafka
  Issue Type: Sub-task
Reporter: Akhilesh Chaganti
Assignee: Akhilesh Chaganti






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

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.3 #133

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 421414 lines...]
[2022-12-10T00:41:28.038Z] KafkaZkClientTest > testChroot(boolean) > 
kafka.zk.KafkaZkClientTest.testChroot(boolean)[1] PASSED
[2022-12-10T00:41:28.038Z] 
[2022-12-10T00:41:28.038Z] KafkaZkClientTest > testChroot(boolean) > 
kafka.zk.KafkaZkClientTest.testChroot(boolean)[2] STARTED
[2022-12-10T00:41:28.967Z] 
[2022-12-10T00:41:28.967Z] KafkaZkClientTest > testChroot(boolean) > 
kafka.zk.KafkaZkClientTest.testChroot(boolean)[2] PASSED
[2022-12-10T00:41:28.967Z] 
[2022-12-10T00:41:28.967Z] KafkaZkClientTest > testRegisterBrokerInfo() STARTED
[2022-12-10T00:41:28.967Z] 
[2022-12-10T00:41:28.967Z] KafkaZkClientTest > testRegisterBrokerInfo() PASSED
[2022-12-10T00:41:28.967Z] 
[2022-12-10T00:41:28.967Z] KafkaZkClientTest > testRetryRegisterBrokerInfo() 
STARTED
[2022-12-10T00:41:29.896Z] 
[2022-12-10T00:41:29.896Z] KafkaZkClientTest > testRetryRegisterBrokerInfo() 
PASSED
[2022-12-10T00:41:29.896Z] 
[2022-12-10T00:41:29.896Z] KafkaZkClientTest > testConsumerOffsetPath() STARTED
[2022-12-10T00:41:29.896Z] 
[2022-12-10T00:41:29.896Z] KafkaZkClientTest > testConsumerOffsetPath() PASSED
[2022-12-10T00:41:29.896Z] 
[2022-12-10T00:41:29.896Z] KafkaZkClientTest > 
testDeleteRecursiveWithControllerEpochVersionCheck() STARTED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > 
testDeleteRecursiveWithControllerEpochVersionCheck() PASSED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > testTopicAssignments() STARTED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > testTopicAssignments() PASSED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > 
testControllerManagementMethods() STARTED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > 
testControllerManagementMethods() PASSED
[2022-12-10T00:41:30.825Z] 
[2022-12-10T00:41:30.825Z] KafkaZkClientTest > testTopicAssignmentMethods() 
STARTED
[2022-12-10T00:41:31.919Z] 
[2022-12-10T00:41:31.919Z] KafkaZkClientTest > testTopicAssignmentMethods() 
PASSED
[2022-12-10T00:41:31.919Z] 
[2022-12-10T00:41:31.919Z] KafkaZkClientTest > testConnectionViaNettyClient() 
STARTED
[2022-12-10T00:41:31.919Z] 
[2022-12-10T00:41:31.919Z] KafkaZkClientTest > testConnectionViaNettyClient() 
PASSED
[2022-12-10T00:41:31.919Z] 
[2022-12-10T00:41:31.919Z] KafkaZkClientTest > testPropagateIsrChanges() STARTED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testPropagateIsrChanges() PASSED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testControllerEpochMethods() 
STARTED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testControllerEpochMethods() 
PASSED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testDeleteRecursive() STARTED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testDeleteRecursive() PASSED
[2022-12-10T00:41:32.849Z] 
[2022-12-10T00:41:32.849Z] KafkaZkClientTest > testGetTopicPartitionStates() 
STARTED
[2022-12-10T00:41:33.778Z] 
[2022-12-10T00:41:33.778Z] KafkaZkClientTest > testGetTopicPartitionStates() 
PASSED
[2022-12-10T00:41:33.778Z] 
[2022-12-10T00:41:33.778Z] KafkaZkClientTest > 
testCreateConfigChangeNotification() STARTED
[2022-12-10T00:41:33.778Z] 
[2022-12-10T00:41:33.778Z] KafkaZkClientTest > 
testCreateConfigChangeNotification() PASSED
[2022-12-10T00:41:33.778Z] 
[2022-12-10T00:41:33.778Z] KafkaZkClientTest > testDelegationTokenMethods() 
STARTED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] KafkaZkClientTest > testDelegationTokenMethods() 
PASSED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() STARTED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] ZooKeeperClientTest > 
testZNodeChangeHandlerForDataChange() PASSED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() STARTED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] ZooKeeperClientTest > 
testZooKeeperSessionStateMetric() PASSED
[2022-12-10T00:41:34.707Z] 
[2022-12-10T00:41:34.707Z] ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() STARTED
[2022-12-10T00:41:35.636Z] 
[2022-12-10T00:41:35.636Z] ZooKeeperClientTest > 
testExceptionInBeforeInitializingSession() PASSED
[2022-12-10T00:41:35.636Z] 
[2022-12-10T00:41:35.636Z] ZooKeeperClientTest > testGetChildrenExistingZNode() 
STARTED
[2022-12-10T00:41:35.636Z] 
[2022-12-10T00:41:35.636Z] ZooKeeperClientTest > testGetChildrenExistingZNode() 
PASSED
[2022-12-10T00:41:35.636Z] 
[2022-12-10T00:41:35.636Z] ZooKeeperClientTest > testConnection() STARTED
[2022-12-10T00:41:35.636Z] 
[2022-12-10T00:41:35.636Z] ZooKeeperClientTest > testConnection() PASSED
[2022-12-10T00:41:35.636Z] 

[jira] [Created] (KAFKA-14457) Inconsistent in quorum controller fenced broker metric

[Jira]

José Armando García Sancio created KAFKA-14457:
--

 Summary: Inconsistent in quorum controller fenced broker metric
 Key: KAFKA-14457
 URL: https://issues.apache.org/jira/browse/KAFKA-14457
 Project: Kafka
  Issue Type: Bug
Affects Versions: 3.3.1, 3.2.3, 3.2.2, 3.2.1, 3.1.2, 3.3.0, 3.1.1, 3.2.0, 
3.1.0
Reporter: José Armando García Sancio
Assignee: José Armando García Sancio


It is possible for controllers to replay a record twice. This happens when the 
active controller replays an uncommitted record, resigns and replays the same 
record when it becomes committed.

The controller handles these transition changes by using timeline data 
structures and reverting to previous in-memory snapshots.

This functionality is not used when computing the fenced and unfenced metrics. 
Specifically, the metric can over count when executing this code:
{code:java}
   } else if (prevRegistration == null) {
  if (registration.fenced()) {
  
controllerMetrics.setFencedBrokerCount(controllerMetrics.fencedBrokerCount() + 
1);
  log.info("Added new fenced broker: {}", registration.id());
  } else {
  
controllerMetrics.setActiveBrokerCount(controllerMetrics.activeBrokerCount() + 
1);
  log.info("Added new unfenced broker: {}", registration.id());
  }{code}
>From {{ClusterControlManager::updateMetrics.}}



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

Build failed in Jenkins: Kafka » Kafka Branch Builder » trunk #1421

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 520083 lines...]
[2022-12-09T23:41:08.174Z] > Task :server-common:compileTestJava UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :server-common:testClasses UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :connect:json:compileTestJava UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :connect:json:testClasses UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :group-coordinator:compileTestJava NO-SOURCE
[2022-12-09T23:41:08.174Z] > Task :group-coordinator:testClasses UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :connect:json:testJar
[2022-12-09T23:41:08.174Z] > Task :raft:compileTestJava UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :raft:testClasses UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :connect:json:testSrcJar
[2022-12-09T23:41:08.174Z] > Task 
:streams:generateMetadataFileForMavenJavaPublication
[2022-12-09T23:41:08.174Z] > Task :metadata:compileTestJava UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task :metadata:testClasses UP-TO-DATE
[2022-12-09T23:41:08.174Z] > Task 
:clients:generateMetadataFileForMavenJavaPublication
[2022-12-09T23:41:08.174Z] > Task 
:clients:generatePomFileForMavenJavaPublication
[2022-12-09T23:41:11.770Z] 
[2022-12-09T23:41:11.770Z] > Task :streams:javadoc
[2022-12-09T23:41:11.770Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/processor/StreamPartitioner.java:54:
 warning - Tag @link: reference not found: 
org.apache.kafka.clients.producer.internals.DefaultPartitioner
[2022-12-09T23:41:11.770Z] 
[2022-12-09T23:41:11.770Z] > Task :connect:api:javadoc
[2022-12-09T23:41:12.703Z] > Task :connect:api:copyDependantLibs UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task :connect:api:jar UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task 
:connect:api:generateMetadataFileForMavenJavaPublication
[2022-12-09T23:41:12.704Z] > Task :connect:json:copyDependantLibs UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task :connect:json:jar UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task 
:connect:json:generateMetadataFileForMavenJavaPublication
[2022-12-09T23:41:12.704Z] > Task :connect:api:javadocJar
[2022-12-09T23:41:12.704Z] 
[2022-12-09T23:41:12.704Z] > Task :clients:javadoc
[2022-12-09T23:41:12.704Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/clients/src/main/java/org/apache/kafka/common/security/oauthbearer/OAuthBearerLoginCallbackHandler.java:151:
 warning - Tag @link: reference not found: 
[2022-12-09T23:41:12.704Z] 
[2022-12-09T23:41:12.704Z] > Task :connect:api:compileTestJava UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task :connect:api:testClasses UP-TO-DATE
[2022-12-09T23:41:12.704Z] > Task 
:connect:json:publishMavenJavaPublicationToMavenLocal
[2022-12-09T23:41:12.704Z] > Task :connect:json:publishToMavenLocal
[2022-12-09T23:41:12.704Z] > Task :connect:api:testJar
[2022-12-09T23:41:12.704Z] > Task :connect:api:testSrcJar
[2022-12-09T23:41:12.704Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2022-12-09T23:41:12.704Z] > Task :connect:api:publishToMavenLocal
[2022-12-09T23:41:13.637Z] 
[2022-12-09T23:41:13.637Z] > Task :streams:javadoc
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:854:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:890:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:919:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/KStream.java:939:
 warning - Tag @link: reference not found: DefaultPartitioner
[2022-12-09T23:41:13.637Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk@2/streams/src/main/java/org/apache/kafka/streams/kstream/Produced.java:84:
 warning - Tag @link: reference not found: DefaultPartitioner

Re: [Streams] GlobalStateManagerImpl#restoreState locally restores previously deleted records

[Colt McNealy]

Does the KeySerde that you provided to your store encrypt the keys? I've
never done so myself, but I've seen others report similar behavior (the
store iterator shows the correct values but store.get('foo') returns null)
in the Confluent Community slack. Here's a relevant message:

> "From the behaviour in your code snippet above, I would say that the key
is stored in encrypted form. The deserializer decrypts it correctly (thus
you see the key and value while iterating). But when you requests the key
individually you are passing it in plain text (the serializer might not be
encrypting) and it’s not found in the keystore."

I can't help too much beyond that; but you may want to look into that issue.

Colt McNealy
*Founder, LittleHorse.io*


On Thu, Dec 8, 2022 at 11:51 PM Patrick D’Addona
 wrote:

> > In your case you also delete if the value is not null and if the value
> not-equals "deleteme", right? Ie, you use non-tombstone records as deletes
> what is just not allowed/supported.
>
> The "deleteme" String was only for testing, the issue also happens without
> it, i.e. if there is a "real" tombstone with `value == null` on the input
> topic.
> I do use the input topic as a changelog for my global table. tombstones
> are sent directly to that topic from a kafka streams operation before the
> actual store.
>
> > I cannot explain why all() and get(key) actually give you different
> result with respect to `key`. If a key is resurrected during a restore,
> both method should return it. Not sure why `get(key)` returns `null`
> even if `all()` contains the key... I would rather expect that both
> return the resurrected key.
>
> That's why I think this is different from KAFKA-7663.
> The **foo.bar.globaltopic** topic currently looks like this
> |timestamp|key|value|
> |2022-08-10T14:23:51.768|foo|foo|
> |2022-08-10T14:23:51.836|foo|foo|
> |2022-08-10T14:23:52.126|bar|bar|
> |2022-08-10T14:23:52.398|foo|foo|
> |2022-08-10T14:23:53.353|bar|bar|
> |2022-08-10T14:23:53.098|foo||
> |2022-08-10T14:23:54.367|bar|bar|
>
> After I delete the kafka-streams.state.dir and restart the application, I
> get
> store.get("foo") -> null
> store.get("bar") -> "bar"
> store.all() -> "foo" and "bar"
>
> Hope that explains it better.
>
> - Patrick
>
>
>
>
> Patrick D’Addona
> Senior Lead IT Architect
>
>
> Mobile: +49 151 544 22 161
> patrick.dadd...@maibornwolff.de
> Theresienhöhe 13, 80339 München
>
> MaibornWolff GmbH, Theresienhoehe 13, D-80339 Munich, Germany
> www.maibornwolff.de, Phone +49 89 544 253 000
> USt-ID DE 129 299 525, Munich District Court HRB 98058
> Managing Directors: Volker Maiborn, Holger Wolff, Alexander Hofmann,
> Florian Theimer, Marcus Adlwart, Dr. Martina Beck, Christian Loos.
> 
>
> 
> From: Matthias J. Sax 
> Sent: Friday, December 9, 2022 01:11
> To: dev@kafka.apache.org 
> Subject: Re: [Streams] GlobalStateManagerImpl#restoreState locally
> restores previously deleted records
>
> > The way I see it, KAFKA-7663 says, "a global store will be exactly the
> input topic after restore, regardless of the processor"
>
> Not sure what you mean by this? The issue the tickets describe is, that
> if you don't do a plain `put(key,value)` in your processor, stuff breaks
> right now. (Note that `delete(key)` and `put(key,null)` is the same).
>
>
> It's a known issue, bad API, and also bad documentation on our side, and
> I guess you can call it a bug if you wish. However, you can only use
> tombstones as deletes right now. Thus, what you do "wrong" is
>
> > if (record.value() == null == record.value().equals("deleteme")) {
> > store.delete(record.key());
> > }
>
> In your case you also delete if the value is not null and if the value
> not-equals "deleteme", right? Ie, you use non-tombstone records as
> deletes what is just not allowed/supported.
>
> The issue is that during restore only `null` values, ie, actual
> tombstones are handled as deletes and thus, if you delete a key using a
> non-tombstone record in your processor, this key can be resurrected
> during restore.
>
>
> I cannot explain why all() and get(key) actually give you different
> result with respect to `key`. If a key is resurrected during a restore,
> both method should return it. Not sure why `get(key)` returns `null`
> even if `all()` contains the key... I would rather expect that both
> return the resurrected key.
>
> Hope this helps.
>
>
> -Matthias
>
>
> On 12/8/22 12:00 PM, Patrick D’Addona wrote:
> > Hi,
> >
> > I don't think this issue is exactly the same as KAFKA-7663.
> >
> > The way I see it, KAFKA-7663 says, "a global store will be exactly the
> input topic after restore, regardless of the processor"
> > My issue here, is that the global store after restore is inconsistent
> with the input topic and the store itself.
> > Because it finds records with key "foo" using **store.all()** that it
> can not find via 

Jenkins build is unstable: Kafka » Kafka Branch Builder » 3.4 #6

[Apache Jenkins Server]

See 

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.2 #94

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 226182 lines...]
[2022-12-09T22:04:03.393Z] 1 warning
[2022-12-09T22:04:04.383Z] 
[2022-12-09T22:04:04.383Z] > Task :connect:api:copyDependantLibs UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task :connect:api:jar UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task 
:connect:api:generateMetadataFileForMavenJavaPublication
[2022-12-09T22:04:04.383Z] > Task :connect:json:copyDependantLibs UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task :connect:json:jar UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task 
:connect:json:generateMetadataFileForMavenJavaPublication
[2022-12-09T22:04:04.383Z] > Task :connect:api:javadocJar
[2022-12-09T22:04:04.383Z] > Task 
:connect:json:publishMavenJavaPublicationToMavenLocal
[2022-12-09T22:04:04.383Z] > Task :connect:json:publishToMavenLocal
[2022-12-09T22:04:04.383Z] > Task :connect:api:compileTestJava UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task :connect:api:testClasses UP-TO-DATE
[2022-12-09T22:04:04.383Z] > Task :connect:api:testJar
[2022-12-09T22:04:04.383Z] > Task :connect:api:testSrcJar
[2022-12-09T22:04:04.383Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2022-12-09T22:04:04.383Z] > Task :connect:api:publishToMavenLocal
[2022-12-09T22:04:06.364Z] 
[2022-12-09T22:04:06.364Z] > Task :streams:javadoc
[2022-12-09T22:04:06.364Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/TopologyConfig.java:58:
 warning - Tag @link: missing '#': "org.apache.kafka.streams.StreamsBuilder()"
[2022-12-09T22:04:06.364Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/TopologyConfig.java:58:
 warning - Tag @link: can't find org.apache.kafka.streams.StreamsBuilder() in 
org.apache.kafka.streams.TopologyConfig
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/Position.java:44:
 warning - Tag @link: can't find query(Query,
[2022-12-09T22:04:07.353Z]  PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:44:
 warning - Tag @link: can't find query(Query, PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:36:
 warning - Tag @link: can't find query(Query, PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:57:
 warning - Tag @link: can't find query(Query, PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:74:
 warning - Tag @link: can't find query(Query, PositionBound, boolean) in 
org.apache.kafka.streams.processor.StateStore
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:110:
 warning - Tag @link: reference not found: this#getResult()
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:117:
 warning - Tag @link: reference not found: this#getFailureReason()
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:117:
 warning - Tag @link: reference not found: this#getFailureMessage()
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:155:
 warning - Tag @link: reference not found: this#isSuccess()
[2022-12-09T22:04:07.353Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/streams/src/main/java/org/apache/kafka/streams/query/QueryResult.java:155:
 warning - Tag @link: reference not found: this#isFailure()
[2022-12-09T22:04:08.341Z] 12 warnings
[2022-12-09T22:04:09.326Z] 
[2022-12-09T22:04:09.326Z] > Task :streams:javadocJar
[2022-12-09T22:04:09.326Z] > Task :streams:compileTestJava UP-TO-DATE
[2022-12-09T22:04:09.326Z] > Task :streams:testClasses UP-TO-DATE
[2022-12-09T22:04:09.326Z] 
[2022-12-09T22:04:09.326Z] > Task :clients:javadoc
[2022-12-09T22:04:09.326Z] 
/home/jenkins/jenkins-agent/workspace/Kafka_kafka_3.2/clients/src/main/java/org/apache/kafka/common/security/oauthbearer/secured/OAuthBearerLoginCallbackHandler.java:147:
 warning - Tag @link: reference not found: 

Build failed in Jenkins: Kafka » Kafka Branch Builder » 3.1 #138

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 367212 lines...]
[2022-12-09T21:51:37.326Z] You can use '--warning-mode all' to show the 
individual deprecation warnings and determine if they come from your own 
scripts or plugins.
[2022-12-09T21:51:37.326Z] 
[2022-12-09T21:51:37.326Z] See 
https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings
[2022-12-09T21:51:37.326Z] 
[2022-12-09T21:51:37.326Z] BUILD SUCCESSFUL in 2h 9m 47s
[2022-12-09T21:51:37.326Z] 205 actionable tasks: 111 executed, 94 up-to-date
[2022-12-09T21:51:37.326Z] 
[2022-12-09T21:51:37.326Z] See the profiling report at: 
file:///home/jenkins/h49-shared/712657a4/workspace/Kafka_kafka_3.1@2/build/reports/profile/profile-2022-12-09-19-41-53.html
[2022-12-09T21:51:37.326Z] A fine-grained performance profile is available: use 
the --scan option.
[Pipeline] junit
[2022-12-09T21:51:39.043Z] Recording test results
[2022-12-09T21:51:47.890Z] 
[2022-12-09T21:51:47.890Z] KRaftClusterTest > 
testCreateClusterAndWaitForBrokerInRunningState() PASSED
[2022-12-09T21:51:47.890Z] 
[2022-12-09T21:51:47.890Z] KRaftClusterTest > 
testCreateClusterAndCreateListDeleteTopic() STARTED
[2022-12-09T21:52:07.461Z] 
[2022-12-09T21:52:07.461Z] KRaftClusterTest > 
testCreateClusterAndCreateListDeleteTopic() PASSED
[2022-12-09T21:52:07.461Z] 
[2022-12-09T21:52:07.461Z] GssapiAuthenticationTest > 
testServerNotFoundInKerberosDatabase() STARTED
[2022-12-09T21:52:27.434Z] 
[2022-12-09T21:52:27.434Z] GssapiAuthenticationTest > 
testServerNotFoundInKerberosDatabase() PASSED
[2022-12-09T21:52:27.434Z] 
[2022-12-09T21:52:27.434Z] GssapiAuthenticationTest > testLoginFailure() STARTED
[2022-12-09T21:52:28.572Z] [Checks API] No suitable checks publisher found.
[Pipeline] echo
[2022-12-09T21:52:28.574Z] Skipping Kafka Streams archetype test for Java 17
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[2022-12-09T21:52:50.168Z] 
[2022-12-09T21:52:50.168Z] GssapiAuthenticationTest > testLoginFailure() PASSED
[2022-12-09T21:52:50.168Z] 
[2022-12-09T21:52:50.168Z] GssapiAuthenticationTest > testRequestIsAReplay() 
STARTED
[2022-12-09T21:53:16.839Z] 
[2022-12-09T21:53:16.839Z] GssapiAuthenticationTest > testRequestIsAReplay() 
PASSED
[2022-12-09T21:53:16.839Z] 
[2022-12-09T21:53:16.839Z] GssapiAuthenticationTest > 
testServerAuthenticationFailure() STARTED
[2022-12-09T21:53:46.007Z] 
[2022-12-09T21:53:46.007Z] GssapiAuthenticationTest > 
testServerAuthenticationFailure() PASSED
[2022-12-09T21:53:46.007Z] 
[2022-12-09T21:53:46.007Z] GssapiAuthenticationTest > testReLogin() STARTED
[2022-12-09T21:54:16.331Z] 
[2022-12-09T21:54:16.331Z] GssapiAuthenticationTest > testReLogin() PASSED
[2022-12-09T21:54:16.331Z] 
[2022-12-09T21:54:16.331Z] ControllerMutationQuotaTest > 
testUnboundedCreateTopicsRequest() STARTED
[2022-12-09T21:54:23.016Z] 
[2022-12-09T21:54:23.016Z] ControllerMutationQuotaTest > 
testUnboundedCreateTopicsRequest() PASSED
[2022-12-09T21:54:23.016Z] 
[2022-12-09T21:54:23.016Z] ControllerMutationQuotaTest > 
testStrictCreatePartitionsRequest() STARTED
[2022-12-09T21:54:34.027Z] 
[2022-12-09T21:54:34.027Z] ControllerMutationQuotaTest > 
testStrictCreatePartitionsRequest() PASSED
[2022-12-09T21:54:34.027Z] 
[2022-12-09T21:54:34.027Z] ControllerMutationQuotaTest > 
testPermissiveCreateTopicsRequest() STARTED
[2022-12-09T21:54:41.169Z] 
[2022-12-09T21:54:41.169Z] ControllerMutationQuotaTest > 
testPermissiveCreateTopicsRequest() PASSED
[2022-12-09T21:54:41.169Z] 
[2022-12-09T21:54:41.169Z] ControllerMutationQuotaTest > 
testStrictDeleteTopicsRequest() STARTED
[2022-12-09T21:54:52.018Z] 
[2022-12-09T21:54:52.018Z] ControllerMutationQuotaTest > 
testStrictDeleteTopicsRequest() PASSED
[2022-12-09T21:54:52.018Z] 
[2022-12-09T21:54:52.018Z] ControllerMutationQuotaTest > testQuotaMetric() 
STARTED
[2022-12-09T21:54:53.958Z] 
[2022-12-09T21:54:53.958Z] ControllerMutationQuotaTest > testQuotaMetric() 
PASSED
[2022-12-09T21:54:53.958Z] 
[2022-12-09T21:54:53.958Z] ControllerMutationQuotaTest > testSetUnsetQuota() 
STARTED
[2022-12-09T21:54:58.602Z] 
[2022-12-09T21:54:58.602Z] ControllerMutationQuotaTest > testSetUnsetQuota() 
PASSED
[2022-12-09T21:54:58.602Z] 
[2022-12-09T21:54:58.602Z] ControllerMutationQuotaTest > 
testUnboundedDeleteTopicsRequest() STARTED
[2022-12-09T21:55:11.086Z] 
[2022-12-09T21:55:11.086Z] ControllerMutationQuotaTest > 
testUnboundedDeleteTopicsRequest() PASSED
[2022-12-09T21:55:11.086Z] 
[2022-12-09T21:55:11.086Z] ControllerMutationQuotaTest > 
testUnboundedCreatePartitionsRequest() STARTED
[2022-12-09T21:55:18.038Z] 
[2022-12-09T21:55:18.038Z] ControllerMutationQuotaTest > 
testUnboundedCreatePartitionsRequest() PASSED

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-875: First-class offsets support in Kafka Connect

[Chris Egerton]

Hi Yash,

The idea with the boolean is to just signify that a connector has
overridden this method, which allows us to issue a definitive response in
the REST API when servicing offset alter/reset requests (described more in
detail here:
https://cwiki.apache.org/confluence/display/KAFKA/KIP-875%3A+First-class+offsets+support+in+Kafka+Connect#KIP875:FirstclassoffsetssupportinKafkaConnect-Altering/resettingoffsets(response)
).

One alternative could be to add some kind of OffsetAlterResult return type
for this method with constructors like "OffsetAlterResult.success()",
"OffsetAlterResult.unknown()" (default), and
"OffsetAlterResult.failure(Throwable t)", but it's hard to envision a
reason to use the "failure" static factory method instead of just throwing
an exception, at which point, we're only left with two reasonable methods:
success, and unknown.

Another could be to add a "boolean canResetOffsets()" method to the
SourceConnector class, but adding a separate method seems like overkill,
and developers may not understand that implementing that method to always
return "false" won't actually cause offset reset requests to not take place.

One final option could be to have something like an AlterOffsetsSupport
enum with values SUPPORTED and UNSUPPORTED and a new "AlterOffsetsSupport
alterOffsetsSupport()" SourceConnector method that returns null by default
(which implicitly maps to the "unknown support" response message in the
REST API). This would line up with the ExactlyOnceSupport API we added in
KIP-618. However, I'm hesitant to adopt it because it's not strictly
necessary to address the cases that we want to cover; everything can be
handled with a single method that gets invoked on offset alter/reset
requests. With exactly-once support, we added this hook because it was
designed to be invoked in a different point in the connector lifecycle.

Cheers,

Chris

On Wed, Dec 7, 2022 at 9:46 AM Yash Mayya  wrote:

> Hi Chris,
>
> Sorry for the late reply.
>
> > I don't believe logging an error message is sufficient for
> > handling failures to reset-after-delete. IMO it's highly
> > likely that users will either shoot themselves in the foot
> > by not reading the fine print and realizing that the offset
> > request may have failed, or will ask for better visibility
> > into the success or failure of the reset request than
> > scanning log files.
>
> Your reasoning for deferring the reset offsets after delete functionality
> to a separate KIP makes sense, thanks for the explanation.
>
> > I've updated the KIP with the
> > developer-facing API changes for this logic
>
> This is great, I hadn't considered the other two (very valid) use-cases for
> such an API, thanks for adding these with elaborate documentation! However,
> the significance / use of the boolean value returned by the two methods is
> not fully clear, could you please clarify?
>
> Thanks,
> Yash
>
> On Fri, Nov 18, 2022 at 1:06 AM Chris Egerton 
> wrote:
>
> > Hi Yash,
> >
> > I've updated the KIP with the correct "kafka_topic", "kafka_partition",
> and
> > "kafka_offset" keys in the JSON examples (settled on those instead of
> > prefixing with "Kafka " for better interactions with tooling like JQ).
> I've
> > also added a note about sink offset requests failing if there are still
> > active members in the consumer group.
> >
> > I don't believe logging an error message is sufficient for handling
> > failures to reset-after-delete. IMO it's highly likely that users will
> > either shoot themselves in the foot by not reading the fine print and
> > realizing that the offset request may have failed, or will ask for better
> > visibility into the success or failure of the reset request than scanning
> > log files. I don't doubt that there are ways to address this, but I would
> > prefer to leave them to a separate KIP since the required design work is
> > non-trivial and I do not feel that the added burden is worth tying to
> this
> > KIP as a blocker.
> >
> > I was really hoping to avoid introducing a change to the developer-facing
> > APIs with this KIP, but after giving it some thought I think this may be
> > unavoidable. It's debatable whether validation of altered offsets is a
> good
> > enough use case on its own for this kind of API, but since there are also
> > connectors out there that manage offsets externally, we should probably
> add
> > a hook to allow those external offsets to be managed, which can then
> serve
> > double- or even-triple duty as a hook to validate custom offsets and to
> > notify users whether offset resets/alterations are supported at all
> (which
> > they may not be if, for example, offsets are coupled tightly with the
> data
> > written by a sink connector). I've updated the KIP with the
> > developer-facing API changes for this logic; let me know what you think.
> >
> > Cheers,
> >
> > Chris
> >
> > On Mon, Nov 14, 2022 at 10:16 AM Mickael Maison <
> mickael.mai...@gmail.com>
> > wrote:
> >
> > > Hi Chris,
> > >
> > 

Re: [VOTE] KIP-837 Allow MultiCasting a Result Record.

[Sagar]

Hey Matthias,

Actually I had shared the PR link for any potential issues that might have
gone missing. I guess it didn't come out that way in my response. Apologies
for that!

I am more than happy to incorporate any feedback/changes or address any
concerns that are still present around this at this point as well.

And I would keep in mind the feedback to provide more time in such a
scenario.

Thanks!
Sagar.

On Fri, Dec 9, 2022 at 11:41 PM Matthias J. Sax  wrote:

> It is what it is.
>
> > we did have internal discussions on this
>
> We sometimes have the case that a KIP need adjustment as stuff is
> discovered during coding. And having a discussion on the PR about it is
> fine. -- However, before the PR gets merge, the KIP change should be
> announced to verify that nobody has objections to he change, before we
> carry forward.
>
> It's up to the committer who reviews/merges the PR to ensure that this
> process is followed IMHO. I hope we can do better next time.
>
> (And yes, there was the 3.4 release KIP deadline that might explain it,
> but it seems important that we give enough time is make "tricky" changes
> and not rush into stuff IMHO.)
>
>
> -Matthias
>
>
> On 12/8/22 7:04 PM, Sagar wrote:
> > Thanks Matthias,
> >
> > Well, as things stand, we did have internal discussions on this and it
> > seemed ok to open it up for IQ and more importantly not ok to have it
> > opened up for FK-Join. And more importantly, the PR for this is already
> > merged and some of these things came up during that. Here's the PR link:
> > https://github.com/apache/kafka/pull/12803.
> >
> > Thanks!
> > Sagar.
> >
> >
> > On Fri, Dec 9, 2022 at 5:15 AM Matthias J. Sax  wrote:
> >
> >> Ah. Missed it as it does not have a nice "code block" similar to
> >> `StreamPartitioner` changes.
> >>
> >> I understand the motivation, but I am wondering if we might head into a
> >> tricky direction? State stores (at least the built-in ones) and IQ are
> >> kinda build with the idea to have sharded data and that a multi-cast of
> >> keys is an anti-pattern?
> >>
> >> Maybe it's fine, but I also don't want to open Pandora's Box. Are we
> >> sure that generalizing the concepts does not cause issues in the future?
> >>
> >> Ie, should we claim that the multi-cast feature should be used for
> >> KStreams only, but not for KTables?
> >>
> >> Just want to double check that we are not doing something we regret
> later.
> >>
> >>
> >> -Matthias
> >>
> >>
> >> On 12/7/22 6:45 PM, Sagar wrote:
> >>> Hi Mathias,
> >>>
> >>> I did save it. The changes are added under Public Interfaces (Pt#2
> about
> >>> enhancing KeyQueryMetadata with partitions method) and
> >>> throwing IllegalArgumentException when StreamPartitioner#partitions
> >> method
> >>> returns multiple partitions for just FK-join instead of the earlier
> >> decided
> >>> FK-Join and IQ.
> >>>
> >>> The background is that for IQ, if the users have multi casted records
> to
> >>> multiple partitions during ingestion but the fetch returns only a
> single
> >>> partition, then it would be wrong. That's why the restriction was
> lifted
> >>> for IQ and that's the reason KeyQueryMetadata now has another
> >> partitions()
> >>> method to signify the same.
> >>>
> >>> FK-Join also has a similar case, but while reviewing it was felt that
> >>> FK-Join on it's own is fairly complicated and we don't need this
> feature
> >>> right away so the restriction still exists.
> >>>
> >>> Thanks!
> >>> Sagar.
> >>>
> >>>
> >>> On Wed, Dec 7, 2022 at 9:42 PM Matthias J. Sax 
> wrote:
> >>>
>  I don't see any update on the wiki about it. Did you forget to hit
> >> "save"?
> 
>  Can you also provide some background? I am not sure right now if I
>  understand the proposed changes?
> 
> 
>  -Matthias
> 
>  On 12/6/22 6:36 PM, Sophie Blee-Goldman wrote:
> > Thanks Sagar, this makes sense to me -- we clearly need additional
>  changes
> > to
> > avoid breaking IQ when using this feature, but I agree with
> continuing
> >> to
> > restrict
> > FKJ since they wouldn't stop working without it, and would become
> much
> > harder
> > to reason about (than they already are) if we did enable them to use
> >> it.
> >
> > And of course, they can still multicast the final results of a FKJ,
> >> they
> > just can't
> > mess with the internal workings of it in this way.
> >
> > On Tue, Dec 6, 2022 at 9:48 AM Sagar 
> >> wrote:
> >
> >> Hi All,
> >>
> >> I made a couple of edits to the KIP which came up during the code
>  review.
> >> Changes at a high level are:
> >>
> >> 1) KeyQueryMetada enhanced to have a new method called partitions().
> >> 2) Lifting the restriction of a single partition for IQ. Now the
> >> restriction holds only for FK Join.
> >>
> >> Updated KIP:
> >>
> 
> >>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211883356
> >>
> >> 

Re: [VOTE] KIP-837 Allow MultiCasting a Result Record.

[Matthias J. Sax]

It is what it is.

we did have internal discussions on this 


We sometimes have the case that a KIP need adjustment as stuff is 
discovered during coding. And having a discussion on the PR about it is 
fine. -- However, before the PR gets merge, the KIP change should be 
announced to verify that nobody has objections to he change, before we 
carry forward.


It's up to the committer who reviews/merges the PR to ensure that this 
process is followed IMHO. I hope we can do better next time.


(And yes, there was the 3.4 release KIP deadline that might explain it, 
but it seems important that we give enough time is make "tricky" changes 
and not rush into stuff IMHO.)



-Matthias


On 12/8/22 7:04 PM, Sagar wrote:

Thanks Matthias,

Well, as things stand, we did have internal discussions on this and it
seemed ok to open it up for IQ and more importantly not ok to have it
opened up for FK-Join. And more importantly, the PR for this is already
merged and some of these things came up during that. Here's the PR link:
https://github.com/apache/kafka/pull/12803.

Thanks!
Sagar.


On Fri, Dec 9, 2022 at 5:15 AM Matthias J. Sax  wrote:


Ah. Missed it as it does not have a nice "code block" similar to
`StreamPartitioner` changes.

I understand the motivation, but I am wondering if we might head into a
tricky direction? State stores (at least the built-in ones) and IQ are
kinda build with the idea to have sharded data and that a multi-cast of
keys is an anti-pattern?

Maybe it's fine, but I also don't want to open Pandora's Box. Are we
sure that generalizing the concepts does not cause issues in the future?

Ie, should we claim that the multi-cast feature should be used for
KStreams only, but not for KTables?

Just want to double check that we are not doing something we regret later.


-Matthias


On 12/7/22 6:45 PM, Sagar wrote:

Hi Mathias,

I did save it. The changes are added under Public Interfaces (Pt#2 about
enhancing KeyQueryMetadata with partitions method) and
throwing IllegalArgumentException when StreamPartitioner#partitions

method

returns multiple partitions for just FK-join instead of the earlier

decided

FK-Join and IQ.

The background is that for IQ, if the users have multi casted records to
multiple partitions during ingestion but the fetch returns only a single
partition, then it would be wrong. That's why the restriction was lifted
for IQ and that's the reason KeyQueryMetadata now has another

partitions()

method to signify the same.

FK-Join also has a similar case, but while reviewing it was felt that
FK-Join on it's own is fairly complicated and we don't need this feature
right away so the restriction still exists.

Thanks!
Sagar.


On Wed, Dec 7, 2022 at 9:42 PM Matthias J. Sax  wrote:


I don't see any update on the wiki about it. Did you forget to hit

"save"?


Can you also provide some background? I am not sure right now if I
understand the proposed changes?


-Matthias

On 12/6/22 6:36 PM, Sophie Blee-Goldman wrote:

Thanks Sagar, this makes sense to me -- we clearly need additional

changes

to
avoid breaking IQ when using this feature, but I agree with continuing

to

restrict
FKJ since they wouldn't stop working without it, and would become much
harder
to reason about (than they already are) if we did enable them to use

it.


And of course, they can still multicast the final results of a FKJ,

they

just can't
mess with the internal workings of it in this way.

On Tue, Dec 6, 2022 at 9:48 AM Sagar 

wrote:



Hi All,

I made a couple of edits to the KIP which came up during the code

review.

Changes at a high level are:

1) KeyQueryMetada enhanced to have a new method called partitions().
2) Lifting the restriction of a single partition for IQ. Now the
restriction holds only for FK Join.

Updated KIP:




https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211883356


Thanks!
Sagar.

On Mon, Sep 12, 2022 at 6:43 PM Sagar 

wrote:



Thanks Bruno,

Marking this as accepted.

Thanks everyone for their comments/feedback.

Thanks!
Sagar.

On Mon, Sep 12, 2022 at 1:53 PM Bruno Cadonna 

wrote:



Hi Sagar,

Thanks for the update and the PR!

+1 (binding)

Best,
Bruno

On 10.09.22 18:57, Sagar wrote:

Hi Bruno,

Thanks, I think these changes make sense to me. I have updated the

KIP

accordingly.

Thanks!
Sagar.

On Wed, Sep 7, 2022 at 2:16 PM Bruno Cadonna 

wrote:



Hi Sagar,

I would not drop the support for dropping records. I would also

not

return null from partitions(). Maybe an Optional can help here. An

empty

Optional would mean to use the default partitioning behavior of

the

producer. So we would have:

- non-empty Optional, non-empty list of integers: partitions to

send

the

record to
- non-empty Optional, empty list of integers: drop the record
- empty Optional: use default behavior

What do other think?

Best,
Bruno

On 02.09.22 13:53, Sagar wrote:

Hello Bruno/Chris,

Since these are the last set of changes(I am assuming haha), it

would

be

great 

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] Apache Kafka 3.4.0 release

[Divij Vaidya]

Hey Sophie

I was wondering whether we should try to get the ARM build working again so
that we can perform release qualification of 3.4.x on ARM as well (which
was disabled in https://github.com/apache/kafka/pull/12380)? I would be
happy to pick up the work if someone can point me to the history on this
subject.

--
Divij Vaidya



On Thu, Dec 8, 2022 at 3:48 AM Sophie Blee-Goldman
 wrote:

> Thanks everyone for the updates, that all sounds good.
>
> Divij: I pinged some of the relevant reviewers to give your PRs a final
> pass, but will
> leave it to their judgement from here as I'm not familiar with either.
>
> Everyone else: reminder that today is the official code freeze deadline, so
> please try
> and get your PRs in by EOD! If you have something on the edge and worry
> it's not
> ready, feel free to reach out for an extension: I'd rather give you an
> extra day or two
> than risk finding a blocker weeks from now because a PR was rushed :)
>
> On Wed, Dec 7, 2022 at 2:04 PM Chris Egerton 
> wrote:
>
> > Hi Sophie,
> >
> > Thanks for taking a look at the MM2 issue. We've merged a
> > (minimally-scoped) fix and backported it to the 3.4 branch; the issue
> > should be resolved now.
> >
> > Cheers,
> >
> > Chris
> >
> > On Wed, Dec 7, 2022 at 3:12 PM Rajini Sivaram 
> > wrote:
> >
> > > Hi Sophie,
> > >
> > > I have merged PR #12954 for KIP-881 to 3.4 branch. Please let me know
> if
> > > that is ok.
> > >
> > > Thank you,
> > >
> > > Rajini
> > >
> > >
> > > On Wed, Dec 7, 2022 at 11:43 AM Rajini Sivaram <
> rajinisiva...@gmail.com>
> > > wrote:
> > >
> > > > Hi Sophie,
> > > >
> > > > The first PR for KIP-881 which contains protocol changes has been
> > merged
> > > > to trunk (https://github.com/apache/kafka/pull/12954). It is a
> > > relatively
> > > > small PR, can we merge to 3.4.0?
> > > >
> > > > Thank you,
> > > >
> > > > Rajini
> > > >
> > > >
> > > > On Wed, Dec 7, 2022 at 11:16 AM Divij Vaidya <
> divijvaidy...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hey Sophie
> > > >>
> > > >> I have a couple of pending PRs which have been waiting for review
> > since
> > > >> preparation of the 3.3 release. They are not blockers for 3.4 but
> are
> > > >> being
> > > >> tracked as improvements that we would like to add to 3.4 release.
> > > >>
> > > >> Please consider taking a look when you get a chance:
> > > >>
> > > >> 1. https://issues.apache.org/jira/browse/KAFKA-7109
> > > >> 2. https://github.com/apache/kafka/pull/12228
> > > >>
> > > >> --
> > > >> Divij Vaidya
> > > >>
> > > >>
> > > >>
> > > >> On Wed, Dec 7, 2022 at 3:18 AM Sophie Blee-Goldman
> > > >>  wrote:
> > > >>
> > > >> > Hey all,
> > > >> >
> > > >> > First off, just a heads up that code freeze will be *tomorrow, Dec
> > > 6th*
> > > >> so
> > > >> > please make sure
> > > >> > to merge any lingering PRs by EOD Wednesday (PST). If you have a
> > > >> potential
> > > >> > blocker
> > > >> > that may take longer to fix and hasn't already been communicated
> to
> > > me,
> > > >> > please reach out
> > > >> > to me now and make sure the ticket is marked as a blocker for 3.4
> > > >> >
> > > >> > Also note that the 3.4 branch has been created, so going forward
> > > you'll
> > > >> > need to ensure that
> > > >> > newly merged PRs are cherrypicked to this branch to make the 3.4
> > > >> release.
> > > >> >
> > > >> > Thanks, and don't hesitate to reach out if you have any questions.
> > > >> >
> > > >> > Greg/Chris -- I looked over the ticket and PR and agree this
> counts
> > > as a
> > > >> > blocker so just try
> > > >> > and get this in as quickly as is reasonable. It seems like things
> > are
> > > >> > mostly sorted with this
> > > >> > fix but I did chime in on the PR discussion regarding keeping the
> > > scope
> > > >> > small here
> > > >> >
> > > >> >
> > > >> > On Tue, Dec 6, 2022 at 7:15 AM Chris Egerton
> >  > > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hi Greg,
> > > >> > >
> > > >> > > Thanks for finding and raising this issue. I've given the PR a
> > look
> > > >> and
> > > >> > > plan to continue reviewing it this week until merged. IMO this
> > > should
> > > >> > > qualify as a blocker for the release.
> > > >> > >
> > > >> > > Sophie, is it alright if we merge this into the 3.4 branch (or
> > > trunk,
> > > >> if
> > > >> > > one has not been created yet) past the December 7th code freeze
> > > >> deadline?
> > > >> > >
> > > >> > > Cheers,
> > > >> > >
> > > >> > > Chris
> > > >> > >
> > > >> > > On Mon, Dec 5, 2022 at 2:11 PM Greg Harris
> > > >>  > > >> > >
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Hi All,
> > > >> > > >
> > > >> > > > Just notifying everyone of a regression introduced by KIP-787,
> > > >> > currently
> > > >> > > > only present on trunk, but which may qualify as a blocker for
> > the
> > > >> > > release.
> > > >> > > > It manifests as a moderate resource leak on MirrorMaker2
> > clusters.
> > > >> The
> > > >> > > fix
> > > >> > > > should have a small scope and low risk.
> > > >> > > >

[jira] [Resolved] (KAFKA-14413) Separate MirrorMaker configurations for each connector

[Chris Egerton (Jira)]

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

Chris Egerton resolved KAFKA-14413.
---
Fix Version/s: 3.4.0
   Resolution: Done

> Separate MirrorMaker configurations for each connector
> --
>
> Key: KAFKA-14413
> URL: https://issues.apache.org/jira/browse/KAFKA-14413
> Project: Kafka
>  Issue Type: Bug
>  Components: mirrormaker
>Reporter: Mickael Maison
>Assignee: Mickael Maison
>Priority: Major
> Fix For: 3.4.0
>
>
> Currently all the MirrorMaker configurations are put together in the 
> MirrorConnectorConfig. When using the /connector-plugins//config, it 
> returns the configurations of all MirrorMaker connectors.
> This also makes it hard to generate documentation for the connectors as it's 
> not possible to link configurations to specific connectors.
> We should split the configuration into different classes to address this 
> issue.
>  
>  
>  
>  



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

[jira] [Reopened] (KAFKA-14391) Add ConsumerGroupHeartbeat API

[David Jacot (Jira)]

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

David Jacot reopened KAFKA-14391:
-

> Add ConsumerGroupHeartbeat API
> --
>
> Key: KAFKA-14391
> URL: https://issues.apache.org/jira/browse/KAFKA-14391
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: David Jacot
>Assignee: David Jacot
>Priority: Major
> Fix For: 3.5.0
>
>
> Add ConsumerGroupHeartbeat API and gate it by a hidden feature flag.



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

[jira] [Resolved] (KAFKA-14425) The Kafka protocol should support nullable structs

[David Jacot (Jira)]

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

David Jacot resolved KAFKA-14425.
-
Fix Version/s: 3.5.0
   Resolution: Fixed

> The Kafka protocol should support nullable structs
> --
>
> Key: KAFKA-14425
> URL: https://issues.apache.org/jira/browse/KAFKA-14425
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: David Jacot
>Assignee: David Jacot
>Priority: Major
> Fix For: 3.5.0
>
>




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

[jira] [Resolved] (KAFKA-14391) Add ConsumerGroupHeartbeat API

[David Jacot (Jira)]

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

David Jacot resolved KAFKA-14391.
-
Fix Version/s: 3.5.0
   Resolution: Fixed

> Add ConsumerGroupHeartbeat API
> --
>
> Key: KAFKA-14391
> URL: https://issues.apache.org/jira/browse/KAFKA-14391
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: David Jacot
>Assignee: David Jacot
>Priority: Major
> Fix For: 3.5.0
>
>
> Add ConsumerGroupHeartbeat API and gate it by a hidden feature flag.



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