[jira] [Created] (KAFKA-13284) Use sftp protocol in release.py to upload release candidate artifacts

2021-09-08 Thread Konstantine Karantasis (Jira) 
Konstantine Karantasis created KAFKA-13284:
--

 Summary: Use sftp protocol in release.py to upload release 
candidate artifacts 
 Key: KAFKA-13284
 URL: https://issues.apache.org/jira/browse/KAFKA-13284
 Project: Kafka
  Issue Type: Improvement
Reporter: Konstantine Karantasis
 Fix For: 3.1.0


{{home.apache.org}} has restricted access recently to {{sftp}} only.

This prevents {{release.py}} from uploading a single archive with the artifacts 
of a release candidate using {{rsync}} and then unpacking the archive with 
{{ssh}}



The script could be changed to mirror the contents and upload / delete files 
individually using the {{sftp}} protocol. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (KAFKA-13283) Migrate experimental feature to public API

2021-09-08 Thread A. Sophie Blee-Goldman (Jira) 
A. Sophie Blee-Goldman created KAFKA-13283:
--

 Summary: Migrate experimental feature to public API
 Key: KAFKA-13283
 URL: https://issues.apache.org/jira/browse/KAFKA-13283
 Project: Kafka
  Issue Type: Sub-task
  Components: streams
Reporter: A. Sophie Blee-Goldman






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (KAFKA-13282) Draft final NamedTopology API and publish a KIP

2021-09-08 Thread A. Sophie Blee-Goldman (Jira) 
A. Sophie Blee-Goldman created KAFKA-13282:
--

 Summary: Draft final NamedTopology API and publish a KIP
 Key: KAFKA-13282
 URL: https://issues.apache.org/jira/browse/KAFKA-13282
 Project: Kafka
  Issue Type: Sub-task
  Components: streams
Reporter: A. Sophie Blee-Goldman


The pre-KIP experimental phase has left quite a few open questions around the 
API of this new feature, we need to hash that that out and then write it up 
into a KIP before introducing this in the public interface



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (KAFKA-13281) Support upgrades with dynamic addition/removal of disjoint "named" topologies

2021-09-08 Thread A. Sophie Blee-Goldman (Jira) 
A. Sophie Blee-Goldman created KAFKA-13281:
--

 Summary: Support upgrades with dynamic addition/removal of 
disjoint "named" topologies
 Key: KAFKA-13281
 URL: https://issues.apache.org/jira/browse/KAFKA-13281
 Project: Kafka
  Issue Type: New Feature
  Components: streams
Reporter: A. Sophie Blee-Goldman






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

2021-09-08 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 491132 lines...]
[2021-09-08T23:21:59.810Z] 
[2021-09-08T23:21:59.810Z] PlaintextConsumerTest > testCommitMetadata() STARTED
[2021-09-08T23:22:02.127Z] 
[2021-09-08T23:22:02.127Z] ControllerIntegrationTest > 
testPartitionReassignmentResumesAfterReplicaComesOnline() PASSED
[2021-09-08T23:22:02.127Z] 
[2021-09-08T23:22:02.127Z] ControllerIntegrationTest > 
testLeaderAndIsrWhenEntireIsrOfflineAndUncleanLeaderElectionDisabled() STARTED
[2021-09-08T23:22:06.733Z] 
[2021-09-08T23:22:06.733Z] PlaintextConsumerTest > testCommitMetadata() PASSED
[2021-09-08T23:22:06.733Z] 
[2021-09-08T23:22:06.733Z] PlaintextConsumerTest > testRoundRobinAssignment() 
STARTED
[2021-09-08T23:22:06.921Z] 
[2021-09-08T23:22:06.921Z] ControllerIntegrationTest > 
testLeaderAndIsrWhenEntireIsrOfflineAndUncleanLeaderElectionDisabled() PASSED
[2021-09-08T23:22:06.921Z] 
[2021-09-08T23:22:06.921Z] ControllerIntegrationTest > 
testTopicIdMigrationAndHandlingWithOlderVersion() STARTED
[2021-09-08T23:22:08.900Z] 
[2021-09-08T23:22:08.900Z] ControllerIntegrationTest > 
testTopicIdMigrationAndHandlingWithOlderVersion() PASSED
[2021-09-08T23:22:08.900Z] 
[2021-09-08T23:22:08.900Z] ControllerIntegrationTest > 
testTopicPartitionExpansionWithOfflineReplica() STARTED
[2021-09-08T23:22:13.305Z] 
[2021-09-08T23:22:13.305Z] ControllerIntegrationTest > 
testTopicPartitionExpansionWithOfflineReplica() PASSED
[2021-09-08T23:22:13.305Z] 
[2021-09-08T23:22:13.305Z] ControllerIntegrationTest > 
testPartitionReassignmentToBrokerWithOfflineLogDir() STARTED
[2021-09-08T23:22:20.834Z] 
[2021-09-08T23:22:20.834Z] PlaintextConsumerTest > testRoundRobinAssignment() 
PASSED
[2021-09-08T23:22:20.834Z] 
[2021-09-08T23:22:20.834Z] PlaintextConsumerTest > testPatternSubscription() 
STARTED
[2021-09-08T23:22:21.451Z] 
[2021-09-08T23:22:21.451Z] ControllerIntegrationTest > 
testPartitionReassignmentToBrokerWithOfflineLogDir() PASSED
[2021-09-08T23:22:21.451Z] 
[2021-09-08T23:22:21.451Z] ControllerIntegrationTest > 
testPreferredReplicaLeaderElectionWithOfflinePreferredReplica() STARTED
[2021-09-08T23:22:24.653Z] 
[2021-09-08T23:22:24.653Z] ControllerIntegrationTest > 
testPreferredReplicaLeaderElectionWithOfflinePreferredReplica() PASSED
[2021-09-08T23:22:24.653Z] 
[2021-09-08T23:22:24.653Z] ControllerIntegrationTest > 
testMetadataPropagationOnControlPlane() STARTED
[2021-09-08T23:22:26.897Z] 
[2021-09-08T23:22:26.897Z] ControllerIntegrationTest > 
testMetadataPropagationOnControlPlane() PASSED
[2021-09-08T23:22:26.897Z] 
[2021-09-08T23:22:26.897Z] ControllerIntegrationTest > 
testControllerFeatureZNodeSetupWhenFeatureVersioningIsEnabledWithNonExistingFeatureZNode()
 STARTED
[2021-09-08T23:22:28.971Z] 
[2021-09-08T23:22:28.971Z] ControllerIntegrationTest > 
testControllerFeatureZNodeSetupWhenFeatureVersioningIsEnabledWithNonExistingFeatureZNode()
 PASSED
[2021-09-08T23:22:28.971Z] 
[2021-09-08T23:22:28.971Z] ControllerIntegrationTest > testAlterIsrErrors() 
STARTED
[2021-09-08T23:22:31.216Z] 
[2021-09-08T23:22:31.216Z] ControllerIntegrationTest > testAlterIsrErrors() 
PASSED
[2021-09-08T23:22:31.216Z] 
[2021-09-08T23:22:31.216Z] ControllerIntegrationTest > 
testAutoPreferredReplicaLeaderElection() STARTED
[2021-09-08T23:22:37.888Z] 
[2021-09-08T23:22:37.888Z] PlaintextConsumerTest > testPatternSubscription() 
PASSED
[2021-09-08T23:22:38.695Z] 
[2021-09-08T23:22:38.695Z] ControllerIntegrationTest > 
testAutoPreferredReplicaLeaderElection() PASSED
[2021-09-08T23:22:38.695Z] 
[2021-09-08T23:22:38.695Z] ControllerIntegrationTest > testTopicCreation() 
STARTED
[2021-09-08T23:22:38.970Z] 
[2021-09-08T23:22:38.970Z] Deprecated Gradle features were used in this build, 
making it incompatible with Gradle 8.0.
[2021-09-08T23:22:38.970Z] 
[2021-09-08T23:22:38.970Z] You can use '--warning-mode all' to show the 
individual deprecation warnings and determine if they come from your own 
scripts or plugins.
[2021-09-08T23:22:38.970Z] 
[2021-09-08T23:22:38.970Z] See 
https://docs.gradle.org/7.2/userguide/command_line_interface.html#sec:command_line_warnings
[2021-09-08T23:22:38.970Z] 
[2021-09-08T23:22:38.970Z] BUILD SUCCESSFUL in 2h 1m 6s
[2021-09-08T23:22:38.970Z] 202 actionable tasks: 109 executed, 93 up-to-date
[2021-09-08T23:22:38.970Z] 
[2021-09-08T23:22:38.970Z] See the profiling report at: 
file:///home/jenkins/jenkins-agent/workspace/Kafka_kafka_trunk/build/reports/profile/profile-2021-09-08-21-21-37.html
[2021-09-08T23:22:38.970Z] A fine-grained performance profile is available: use 
the --scan option.
[Pipeline] junit
[2021-09-08T23:22:40.000Z] Recording test results
[2021-09-08T23:22:40.672Z] 
[2021-09-08T23:22:40.672Z] ControllerIntegrationTest > testTopicCreation() 
PASSED
[2021-09-08T23:22:40.672Z] 
[2021-09-08T23:22:40.672Z] ControllerIntegrationTest > 
testControllerFeatureZNodeSetupWhenFeatureVersioningIsDisabledWith

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #130

2021-09-08 Thread Apache Jenkins Server 
See

[VOTE] 3.0.0 RC2

2021-09-08 Thread Konstantine Karantasis 
Hello again Kafka users, developers and client-developers,

This is the third candidate for release of Apache Kafka 3.0.0.
It is a major release that includes many new features, including:

* The deprecation of support for Java 8 and Scala 2.12.
* Kafka Raft support for snapshots of the metadata topic and other
improvements in the self-managed quorum.
* Deprecation of message formats v0 and v1.
* Stronger delivery guarantees for the Kafka producer enabled by default.
* Optimizations in OffsetFetch and FindCoordinator requests.
* More flexible Mirror Maker 2 configuration and deprecation of Mirror
Maker 1.
* Ability to restart a connector's tasks on a single call in Kafka Connect.
* Connector log contexts and connector client overrides are now enabled by
default.
* Enhanced semantics for timestamp synchronization in Kafka Streams.
* Revamped public API for Stream's TaskId.
* Default serde becomes null in Kafka Streams and several other
configuration changes.

You may read and review a more detailed list of changes in the 3.0.0 blog
post draft here:
https://blogs.apache.org/preview/kafka/?previewEntry=what-s-new-in-apache6

Release notes for the 3.0.0 release:
https://home.apache.org/~kkarantasis/kafka-3.0.0-rc2/RELEASE_NOTES.html

*** Please download, test and vote by Tuesday, September 14, 2021 ***

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/~kkarantasis/kafka-3.0.0-rc2/

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

* Javadoc:
https://home.apache.org/~kkarantasis/kafka-3.0.0-rc2/javadoc/

* Tag to be voted upon (off 3.0 branch) is the 3.0.0 tag:
https://github.com/apache/kafka/releases/tag/3.0.0-rc2

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

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

* Successful Jenkins builds for the 3.0 branch:
Unit/integration tests:
https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.0/129/
(1 flaky test failure)
System tests: https://jenkins.confluent.io/job/system-test-kafka/job/3.0/67/
(1 flaky test failure)

/**

Thanks,
Konstantine

Re: [VOTE] 3.0.0 RC1

2021-09-08 Thread Konstantine Karantasis 
In light of the recent blockers that were reported in the past few days I'm
now closing RC1.
These blockers have now been resolved and RC2 is almost ready, so I will
start a new thread for this new release candidate.

Many thanks to everyone who tested RC1.

Konstantine

On Tue, Aug 31, 2021 at 6:34 PM Konstantine Karantasis <
kkaranta...@apache.org> wrote:

>
> Hello Kafka users, developers and client-developers,
>
> This is the second release candidate for Apache Kafka 3.0.0.
> It corresponds to a major release that includes many new features,
> including:
>
> * The deprecation of support for Java 8 and Scala 2.12.
> * Kafka Raft support for snapshots of the metadata topic and
> other improvements in the self-managed quorum.
> * Deprecation of message formats v0 and v1.
> * Stronger delivery guarantees for the Kafka producer enabled by default.
> * Optimizations in OffsetFetch and FindCoordinator requests.
> * More flexible Mirror Maker 2 configuration and deprecation of
> Mirror Maker 1.
> * Ability to restart a connector's tasks on a single call in Kafka Connect.
> * Connector log contexts and connector client overrides are now enabled
> by default.
> * Enhanced semantics for timestamp synchronization in Kafka Streams.
> * Revamped public API for Stream's TaskId.
> * Default serde becomes null in Kafka Streams and several
> other configuration changes.
>
> You may read and review a more detailed list of changes in the 3.0.0 blog
> post draft here:
>
> https://blogs.apache.org/roller-ui/authoring/preview/kafka/?previewEntry=what-s-new-in-apache6
>
> Release notes for the 3.0.0 release:
> https://home.apache.org/~kkarantasis/kafka-3.0.0-rc1/RELEASE_NOTES.html
>
> *** Please download, test and vote by Wednesday, September 8, 2021 ***
>
> 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/~kkarantasis/kafka-3.0.0-rc1/
>
> * Maven artifacts to be voted upon:
> https://repository.apache.org/content/groups/staging/org/apache/kafka/
>
> * Javadoc:
> https://home.apache.org/~kkarantasis/kafka-3.0.0-rc1/javadoc/
>
> * Tag to be voted upon (off 3.0 branch) is the 3.0.0 tag:
> https://github.com/apache/kafka/releases/tag/3.0.0-rc1
>
> * Documentation:
> https://kafka.apache.org/30/documentation.html
>
> * Protocol:
> https://kafka.apache.org/30/protocol.html
>
> * Successful Jenkins builds for the 3.0 branch:
> Unit/integration tests:
> https://ci-builds.apache.org/blue/organizations/jenkins/Kafka%2Fkafka/detail/3.0/121/pipeline/
> (only few flaky failures)
> System tests:
> https://jenkins.confluent.io/job/system-test-kafka/job/3.0/57/
>
> /**
>
> Thanks,
> Konstantine
>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #129

2021-09-08 Thread Apache Jenkins Server 
See

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

2021-09-08 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 490893 lines...]
[2021-09-08T21:12:01.365Z] 
[2021-09-08T21:12:01.365Z] PlaintextConsumerTest > 
testAutoCommitOnCloseAfterWakeup() STARTED
[2021-09-08T21:12:05.845Z] 
[2021-09-08T21:12:05.845Z] PlaintextConsumerTest > 
testMultiConsumerDefaultAssignor() PASSED
[2021-09-08T21:12:05.845Z] 
[2021-09-08T21:12:05.845Z] PlaintextConsumerTest > testInterceptors() STARTED
[2021-09-08T21:12:06.368Z] 
[2021-09-08T21:12:06.368Z] PlaintextConsumerTest > 
testAutoCommitOnCloseAfterWakeup() PASSED
[2021-09-08T21:12:06.368Z] 
[2021-09-08T21:12:06.368Z] PlaintextConsumerTest > testMaxPollRecords() STARTED
[2021-09-08T21:12:11.856Z] 
[2021-09-08T21:12:11.856Z] PlaintextConsumerTest > testMaxPollRecords() PASSED
[2021-09-08T21:12:11.856Z] 
[2021-09-08T21:12:11.856Z] PlaintextConsumerTest > testAutoOffsetReset() STARTED
[2021-09-08T21:12:12.825Z] 
[2021-09-08T21:12:12.825Z] PlaintextConsumerTest > testInterceptors() PASSED
[2021-09-08T21:12:12.825Z] 
[2021-09-08T21:12:12.825Z] PlaintextConsumerTest > 
testConsumingWithEmptyGroupId() STARTED
[2021-09-08T21:12:16.389Z] 
[2021-09-08T21:12:16.389Z] PlaintextConsumerTest > testAutoOffsetReset() PASSED
[2021-09-08T21:12:16.389Z] 
[2021-09-08T21:12:16.389Z] PlaintextConsumerTest > 
testPerPartitionLagWithMaxPollRecords() STARTED
[2021-09-08T21:12:18.325Z] 
[2021-09-08T21:12:18.325Z] PlaintextConsumerTest > 
testConsumingWithEmptyGroupId() PASSED
[2021-09-08T21:12:18.325Z] 
[2021-09-08T21:12:18.325Z] PlaintextConsumerTest > testPatternUnsubscription() 
STARTED
[2021-09-08T21:12:21.892Z] 
[2021-09-08T21:12:21.892Z] PlaintextConsumerTest > 
testPerPartitionLagWithMaxPollRecords() PASSED
[2021-09-08T21:12:21.892Z] 
[2021-09-08T21:12:21.892Z] PlaintextConsumerTest > testFetchInvalidOffset() 
STARTED
[2021-09-08T21:12:23.802Z] 
[2021-09-08T21:12:23.802Z] PlaintextConsumerTest > testPatternUnsubscription() 
PASSED
[2021-09-08T21:12:23.802Z] 
[2021-09-08T21:12:23.803Z] PlaintextConsumerTest > testGroupConsumption() 
STARTED
[2021-09-08T21:12:26.317Z] 
[2021-09-08T21:12:26.317Z] PlaintextConsumerTest > testFetchInvalidOffset() 
PASSED
[2021-09-08T21:12:26.317Z] 
[2021-09-08T21:12:26.317Z] PlaintextConsumerTest > testAutoCommitIntercept() 
STARTED
[2021-09-08T21:12:30.673Z] 
[2021-09-08T21:12:30.673Z] PlaintextConsumerTest > testGroupConsumption() PASSED
[2021-09-08T21:12:30.673Z] 
[2021-09-08T21:12:30.673Z] PlaintextConsumerTest > testPartitionsFor() STARTED
[2021-09-08T21:12:30.846Z] 
[2021-09-08T21:12:30.847Z] PlaintextConsumerTest > testAutoCommitIntercept() 
PASSED
[2021-09-08T21:12:30.847Z] 
[2021-09-08T21:12:30.847Z] PlaintextConsumerTest > 
testFetchHonoursMaxPartitionFetchBytesIfLargeRecordNotFirst() STARTED
[2021-09-08T21:12:32.962Z] 
[2021-09-08T21:12:32.962Z] PlaintextConsumerTest > testPartitionsFor() PASSED
[2021-09-08T21:12:32.962Z] 
[2021-09-08T21:12:32.962Z] PlaintextConsumerTest > 
testMultiConsumerDefaultAssignorAndVerifyAssignment() STARTED
[2021-09-08T21:12:35.479Z] 
[2021-09-08T21:12:35.479Z] PlaintextConsumerTest > 
testFetchHonoursMaxPartitionFetchBytesIfLargeRecordNotFirst() PASSED
[2021-09-08T21:12:35.479Z] 
[2021-09-08T21:12:35.479Z] PlaintextConsumerTest > testCommitSpecifiedOffsets() 
STARTED
[2021-09-08T21:12:38.344Z] 
[2021-09-08T21:12:38.344Z] PlaintextConsumerTest > 
testMultiConsumerDefaultAssignorAndVerifyAssignment() PASSED
[2021-09-08T21:12:38.344Z] 
[2021-09-08T21:12:38.344Z] PlaintextConsumerTest > testAutoCommitOnRebalance() 
STARTED
[2021-09-08T21:12:41.140Z] 
[2021-09-08T21:12:41.140Z] PlaintextConsumerTest > testCommitSpecifiedOffsets() 
PASSED
[2021-09-08T21:12:41.140Z] 
[2021-09-08T21:12:41.140Z] PlaintextConsumerTest > 
testPerPartitionLeadMetricsCleanUpWithSubscribe() STARTED
[2021-09-08T21:12:43.906Z] 
[2021-09-08T21:12:43.906Z] PlaintextConsumerTest > testAutoCommitOnRebalance() 
PASSED
[2021-09-08T21:12:43.906Z] 
[2021-09-08T21:12:43.906Z] PlaintextConsumerTest > 
testInterceptorsWithWrongKeyValue() STARTED
[2021-09-08T21:12:48.179Z] 
[2021-09-08T21:12:48.179Z] PlaintextConsumerTest > 
testPerPartitionLeadMetricsCleanUpWithSubscribe() PASSED
[2021-09-08T21:12:48.179Z] 
[2021-09-08T21:12:48.179Z] PlaintextConsumerTest > testCommitMetadata() STARTED
[2021-09-08T21:12:49.652Z] 
[2021-09-08T21:12:49.652Z] PlaintextConsumerTest > 
testInterceptorsWithWrongKeyValue() PASSED
[2021-09-08T21:12:49.652Z] 
[2021-09-08T21:12:49.652Z] PlaintextConsumerTest > 
testPerPartitionLeadWithMaxPollRecords() STARTED
[2021-09-08T21:12:52.348Z] 
[2021-09-08T21:12:52.348Z] PlaintextConsumerTest > testCommitMetadata() PASSED
[2021-09-08T21:12:52.348Z] 
[2021-09-08T21:12:52.348Z] PlaintextConsumerTest > testRoundRobinAssignment() 
STARTED
[2021-09-08T21:12:58.355Z] 
[2021-09-08T21:12:58.355Z] PlaintextConsumerTest > 
testPerPartitionLeadWithMaxPollRecords() PASSED
[2021-09-08T21:12:58.355Z] 
[2021-09-08T21:12:58.35

[jira] [Created] (KAFKA-13280) Avoid O(N) behavior in KRaftMetadataCache#topicNamesToIds

2021-09-08 Thread Colin McCabe (Jira) 
Colin McCabe created KAFKA-13280:


 Summary: Avoid O(N) behavior in KRaftMetadataCache#topicNamesToIds
 Key: KAFKA-13280
 URL: https://issues.apache.org/jira/browse/KAFKA-13280
 Project: Kafka
  Issue Type: Improvement
Reporter: Colin McCabe
Assignee: Colin McCabe


Avoid O(N) behavior in KRaftMetadataCache#topicNamesToIds and 
KRaftMetadataCache#topicIdsToNames



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #128

2021-09-08 Thread Apache Jenkins Server 
See

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

2021-09-08 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 492244 lines...]
[2021-09-08T18:47:13.676Z] > Task :raft:testClasses UP-TO-DATE
[2021-09-08T18:47:13.676Z] > Task :connect:json:testJar
[2021-09-08T18:47:13.676Z] > Task :connect:json:testSrcJar
[2021-09-08T18:47:13.676Z] > Task :metadata:compileTestJava UP-TO-DATE
[2021-09-08T18:47:13.676Z] > Task :metadata:testClasses UP-TO-DATE
[2021-09-08T18:47:13.676Z] > Task 
:clients:generateMetadataFileForMavenJavaPublication
[2021-09-08T18:47:13.676Z] > Task 
:clients:generatePomFileForMavenJavaPublication
[2021-09-08T18:47:13.676Z] 
[2021-09-08T18:47:13.676Z] > Task :streams:processMessages
[2021-09-08T18:47:13.676Z] Execution optimizations have been disabled for task 
':streams:processMessages' to ensure correctness due to the following reasons:
[2021-09-08T18:47:13.676Z]   - Gradle detected a problem with the following 
location: 
'/home/jenkins/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.2/userguide/validation_problems.html#implicit_dependency
 for more details about this problem.
[2021-09-08T18:47:13.676Z] MessageGenerator: processed 1 Kafka message JSON 
files(s).
[2021-09-08T18:47:14.605Z] 
[2021-09-08T18:47:14.605Z] > Task :streams:compileJava UP-TO-DATE
[2021-09-08T18:47:14.605Z] > Task :streams:classes UP-TO-DATE
[2021-09-08T18:47:14.605Z] > Task :streams:test-utils:compileJava UP-TO-DATE
[2021-09-08T18:47:14.605Z] > Task :streams:copyDependantLibs
[2021-09-08T18:47:14.605Z] > Task :streams:jar UP-TO-DATE
[2021-09-08T18:47:14.605Z] > Task 
:streams:generateMetadataFileForMavenJavaPublication
[2021-09-08T18:47:18.337Z] > Task :connect:api:javadoc
[2021-09-08T18:47:18.337Z] > Task :connect:api:copyDependantLibs UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task :connect:api:jar UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task 
:connect:api:generateMetadataFileForMavenJavaPublication
[2021-09-08T18:47:18.337Z] > Task :connect:json:copyDependantLibs UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task :connect:json:jar UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task 
:connect:json:generateMetadataFileForMavenJavaPublication
[2021-09-08T18:47:18.337Z] > Task 
:connect:json:publishMavenJavaPublicationToMavenLocal
[2021-09-08T18:47:18.337Z] > Task :connect:json:publishToMavenLocal
[2021-09-08T18:47:18.337Z] > Task :connect:api:javadocJar
[2021-09-08T18:47:18.337Z] > Task :connect:api:compileTestJava UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task :connect:api:testClasses UP-TO-DATE
[2021-09-08T18:47:18.337Z] > Task :connect:api:testJar
[2021-09-08T18:47:18.337Z] > Task :connect:api:testSrcJar
[2021-09-08T18:47:18.337Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2021-09-08T18:47:18.337Z] > Task :connect:api:publishToMavenLocal
[2021-09-08T18:47:21.892Z] > Task :streams:javadoc
[2021-09-08T18:47:21.892Z] > Task :streams:javadocJar
[2021-09-08T18:47:22.870Z] > Task :clients:javadoc
[2021-09-08T18:47:22.870Z] > Task :clients:javadocJar
[2021-09-08T18:47:23.799Z] 
[2021-09-08T18:47:23.799Z] > Task :clients:srcJar
[2021-09-08T18:47:23.799Z] Execution optimizations have been disabled for task 
':clients:srcJar' to ensure correctness due to the following reasons:
[2021-09-08T18:47:23.799Z]   - Gradle detected a problem with the following 
location: 
'/home/jenkins/workspace/Kafka_kafka_trunk/clients/src/generated/java'. Reason: 
Task ':clients:srcJar' uses this output of task ':clients: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.2/userguide/validation_problems.html#implicit_dependency
 for more details about this problem.
[2021-09-08T18:47:24.725Z] 
[2021-09-08T18:47:24.725Z] > Task :clients:testJar
[2021-09-08T18:47:24.725Z] > Task :clients:testSrcJar
[2021-09-08T18:47:24.725Z] > Task 
:clients:publishMavenJavaPublicationToMavenLocal
[2021-09-08T18:47:24.725Z] > Task :clients:publishToMavenLocal
[2021-09-08T18:47:43.839Z] > Task :core:compileScala
[2021-09-08T18:48:51.004Z] > Task :core:classes
[2021-09-08T18:48:51.004Z] > Task :core:compileTestJava NO-SOURCE
[2021-09-08T18:49:21.328Z] > Task :core:compileTestScala
[2021-09-08T18:50:09.946Z] > Task :core:testClasses
[2021-09-08T18:50:24.108Z] > Task :streams:compileTestJava
[2021-09-08T18:50:24.108Z] > Task :streams:testClasses
[2021-09-08T18:50:24.108Z] > Task :streams:testJar
[2021-09-08T18:50:25.036Z] > Task :streams:testSrcJar
[2021-09-08T18:50:25.036Z] > Task 
:streams:publishMavenJavaPublicationToMavenLocal
[20

Re: [VOTE] 3.0.0 RC1

2021-09-08 Thread Konstantine Karantasis 
Thanks David.

Also, somehow I missed Rajini's email on KAFKA-13277. In any case, thanks
Rajini and Colin for fixing this blocker too.

Konstantine



On Wed, Sep 8, 2021 at 7:46 PM David Jacot 
wrote:

> Hi Konstantine,
>
> FYI, we just merged https://issues.apache.org/jira/browse/KAFKA-13266 to
> trunk and to 3.0.
>
> Best,
> David
>
> On Tue, Sep 7, 2021 at 11:25 PM Konstantine Karantasis <
> kkaranta...@apache.org> wrote:
>
> > Thanks for raising this Colin.
> >
> > https://issues.apache.org/jira/browse/KAFKA-13277
> >
> > is a one line fix with a test now. The suggestion to include it in RC2
> > makes sense to me as well. I’ll make sure it’s in.
> >
> > Konstantine
> >
> > On Tue, Sep 7, 2021 at 11:42 PM Colin McCabe  wrote:
> >
> > > Hi Konstantine,
> > >
> > > Given that we are making a new RC, I would suggest that we merge
> > > "KAFKA-13277; Fix size calculation for tagged string fields in message
> > > generator" to 3.0. What do you think?
> > >
> > > best,
> > > Colin
> > >
> > >
> > > On Tue, Sep 7, 2021, at 13:20, Konstantine Karantasis wrote:
> > > > Thanks David,
> > > >
> > > > Assuming we'll have the PRs you mention merged soon, I'll include
> them
> > in
> > > > RC2 for 3.0.0 given their low risk and the fact that we need to
> > generate
> > > a
> > > > new RC anyways.
> > > >
> > > > Konstantine
> > > >
> > > > On Tue, Sep 7, 2021 at 4:43 PM David Jacot
>  > >
> > > > wrote:
> > > >
> > > > > Hi Konstantine,
> > > > >
> > > > > I would like to propose https://github.com/apache/kafka/pull/11300
> > as
> > > a
> > > > > blocker
> > > > > as well. The PR fixes KAFKA-13258/13259/13260. There are all very
> > > small but
> > > > > annoying issues. The PR is trivial.
> > > > >
> > > > > Regarding KAFKA-13266, the fix is quite simple, so low risk in my
> > > opinion.
> > > > > Jason
> > > > > will review it soon.
> > > > >
> > > > > Best,
> > > > > David
> > > > >
> > > > > On Tue, Sep 7, 2021 at 3:27 PM Ismael Juma 
> > wrote:
> > > > >
> > > > > > Hi Konstantine,
> > > > > >
> > > > > > I will remove the final modifier for now.
> > > > > >
> > > > > > I added it because the removal of  the deprecated `close`
> overload
> > > could
> > > > > > lead to weird behavior if the no-args `close` was overridden (the
> > > > > > implementation of the no-arg `close` delegated to the removed
> > > `close`,
> > > > > but
> > > > > > that's no longer the case). However, I didn't realize
> > `MockConsumer`
> > > was
> > > > > a
> > > > > > public class (which is a mistake imo since we tweak its behavior
> > > > > regularly
> > > > > > and sometimes add methods without a KIP).
> > > > > >
> > > > > > Ismael
> > > > > >
> > > > > > On Tue, Sep 7, 2021 at 1:46 AM Konstantine Karantasis <
> > > > > > kkaranta...@apache.org> wrote:
> > > > > >
> > > > > > > Hi Gary,
> > > > > > >
> > > > > > > Regarding KAFKA-13262, this might need a more detailed and
> strong
> > > > > > > justification to be considered as a blocker at this point in
> the
> > > > > release.
> > > > > > > But we are already moving towards RC2 because of the blockers
> > > mentioned
> > > > > > > above, so I'd be in favor of a PR that would revert the change
> > that
> > > > > made
> > > > > > > this method final if we could get one this week. I'm not sure
> why
> > > the
> > > > > > > MockConsumer::close method was marked as final in
> > > > > > > https://github.com/apache/kafka/pull/10438. The change is not
> > > included
> > > > > > in
> > > > > > > the description. Maybe it wasn't obvious that this class is
> used
> > > > > outside
> > > > > > > this project or maybe we thought we should discourage such use.
> > > > > > >
> > > > > > > Gary, is this the only change you are referring to?
> > > > > > > Ismael, I see you authored the PR originally. Any thoughts on
> the
> > > > > > suggested
> > > > > > > change?
> > > > > > >
> > > > > > > Konstantine
> > > > > > >
> > > > > > > On Tue, Sep 7, 2021 at 11:35 AM Konstantine Karantasis <
> > > > > > > kkaranta...@apache.org> wrote:
> > > > > > >
> > > > > > > > Hi Magnus,
> > > > > > > >
> > > > > > > > Thanks for reporting the numbers.
> > > > > > > >
> > > > > > > > I agree that what you observe warrants further investigation,
> > > not so
> > > > > > much
> > > > > > > > because these are clear performance regressions but because
> > they
> > > > > might
> > > > > > be
> > > > > > > > indications of underlying issues, as you noted. However,
> from a
> > > major
> > > > > > > > release standpoint I'd say that such preliminary evidence
> > > probably
> > > > > > falls
> > > > > > > > within the range of acceptable differences in the presence of
> > > major
> > > > > > > changes
> > > > > > > > and can be optimized over time in subsequent releases.
> > > > > > > >
> > > > > > > > Having said that, I'd take Israel's comment one step further
> > and
> > > say
> > > > > > that
> > > > > > > > in order to be able to give more definitive answers it'd be
> > good
> > > to
> > > > > > have
> > > > > > >

[jira] [Created] (KAFKA-13279) Implement CreateTopicsPolicy for KRaft

2021-09-08 Thread Colin McCabe (Jira) 
Colin McCabe created KAFKA-13279:


 Summary: Implement CreateTopicsPolicy for KRaft
 Key: KAFKA-13279
 URL: https://issues.apache.org/jira/browse/KAFKA-13279
 Project: Kafka
  Issue Type: Improvement
Reporter: Colin McCabe
Assignee: Colin McCabe


Implement CreateTopicsPolicy for KRaft



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-8406) kafka-topics throws wrong error on invalid configuration with bootstrap-server and alter config

2021-09-08 Thread Stanislav Kozlovski (Jira) 


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

Stanislav Kozlovski resolved KAFKA-8406.

Fix Version/s: 2.4.0
   Resolution: Fixed

> kafka-topics throws wrong error on invalid configuration with 
> bootstrap-server and alter config
> ---
>
> Key: KAFKA-8406
> URL: https://issues.apache.org/jira/browse/KAFKA-8406
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Stanislav Kozlovski
>Assignee: Stanislav Kozlovski
>Priority: Minor
> Fix For: 2.4.0
>
>
> Running
> {code:java}
> ./kafka-topics --bootstrap-server  --alter --config 
> retention.ms=360 --topic topic{code}
> Results in
> {code:java}
> Missing required argument "[partitions]"{code}
> Running
> {code:java}
> ./kafka-topics --bootstrap-server  --alter --config 
> retention.ms=360 --topic topic --partitions 25{code}
> Results in
> {code:java}
> Option combination "[bootstrap-server],[config]" can't be used with option 
> "[alter]"{code}
> For better clarity, we should just throw the last error outright.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Resolved] (KAFKA-13237) Add ActiveBrokerCount and FencedBrokerCount metrics to the ZK controller (KIP-748)

2021-09-08 Thread David Jacot (Jira) 


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

David Jacot resolved KAFKA-13237.
-
Fix Version/s: 3.1.0
 Reviewer: Jason Gustafson
   Resolution: Fixed

> Add ActiveBrokerCount and FencedBrokerCount metrics to the ZK controller 
> (KIP-748)
> --
>
> Key: KAFKA-13237
> URL: https://issues.apache.org/jira/browse/KAFKA-13237
> Project: Kafka
>  Issue Type: Sub-task
>Reporter: David Jacot
>Assignee: David Jacot
>Priority: Major
> Fix For: 3.1.0
>
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [VOTE] 3.0.0 RC1

2021-09-08 Thread David Jacot 
Hi Konstantine,

FYI, we just merged https://issues.apache.org/jira/browse/KAFKA-13266 to
trunk and to 3.0.

Best,
David

On Tue, Sep 7, 2021 at 11:25 PM Konstantine Karantasis <
kkaranta...@apache.org> wrote:

> Thanks for raising this Colin.
>
> https://issues.apache.org/jira/browse/KAFKA-13277
>
> is a one line fix with a test now. The suggestion to include it in RC2
> makes sense to me as well. I’ll make sure it’s in.
>
> Konstantine
>
> On Tue, Sep 7, 2021 at 11:42 PM Colin McCabe  wrote:
>
> > Hi Konstantine,
> >
> > Given that we are making a new RC, I would suggest that we merge
> > "KAFKA-13277; Fix size calculation for tagged string fields in message
> > generator" to 3.0. What do you think?
> >
> > best,
> > Colin
> >
> >
> > On Tue, Sep 7, 2021, at 13:20, Konstantine Karantasis wrote:
> > > Thanks David,
> > >
> > > Assuming we'll have the PRs you mention merged soon, I'll include them
> in
> > > RC2 for 3.0.0 given their low risk and the fact that we need to
> generate
> > a
> > > new RC anyways.
> > >
> > > Konstantine
> > >
> > > On Tue, Sep 7, 2021 at 4:43 PM David Jacot  >
> > > wrote:
> > >
> > > > Hi Konstantine,
> > > >
> > > > I would like to propose https://github.com/apache/kafka/pull/11300
> as
> > a
> > > > blocker
> > > > as well. The PR fixes KAFKA-13258/13259/13260. There are all very
> > small but
> > > > annoying issues. The PR is trivial.
> > > >
> > > > Regarding KAFKA-13266, the fix is quite simple, so low risk in my
> > opinion.
> > > > Jason
> > > > will review it soon.
> > > >
> > > > Best,
> > > > David
> > > >
> > > > On Tue, Sep 7, 2021 at 3:27 PM Ismael Juma 
> wrote:
> > > >
> > > > > Hi Konstantine,
> > > > >
> > > > > I will remove the final modifier for now.
> > > > >
> > > > > I added it because the removal of  the deprecated `close` overload
> > could
> > > > > lead to weird behavior if the no-args `close` was overridden (the
> > > > > implementation of the no-arg `close` delegated to the removed
> > `close`,
> > > > but
> > > > > that's no longer the case). However, I didn't realize
> `MockConsumer`
> > was
> > > > a
> > > > > public class (which is a mistake imo since we tweak its behavior
> > > > regularly
> > > > > and sometimes add methods without a KIP).
> > > > >
> > > > > Ismael
> > > > >
> > > > > On Tue, Sep 7, 2021 at 1:46 AM Konstantine Karantasis <
> > > > > kkaranta...@apache.org> wrote:
> > > > >
> > > > > > Hi Gary,
> > > > > >
> > > > > > Regarding KAFKA-13262, this might need a more detailed and strong
> > > > > > justification to be considered as a blocker at this point in the
> > > > release.
> > > > > > But we are already moving towards RC2 because of the blockers
> > mentioned
> > > > > > above, so I'd be in favor of a PR that would revert the change
> that
> > > > made
> > > > > > this method final if we could get one this week. I'm not sure why
> > the
> > > > > > MockConsumer::close method was marked as final in
> > > > > > https://github.com/apache/kafka/pull/10438. The change is not
> > included
> > > > > in
> > > > > > the description. Maybe it wasn't obvious that this class is used
> > > > outside
> > > > > > this project or maybe we thought we should discourage such use.
> > > > > >
> > > > > > Gary, is this the only change you are referring to?
> > > > > > Ismael, I see you authored the PR originally. Any thoughts on the
> > > > > suggested
> > > > > > change?
> > > > > >
> > > > > > Konstantine
> > > > > >
> > > > > > On Tue, Sep 7, 2021 at 11:35 AM Konstantine Karantasis <
> > > > > > kkaranta...@apache.org> wrote:
> > > > > >
> > > > > > > Hi Magnus,
> > > > > > >
> > > > > > > Thanks for reporting the numbers.
> > > > > > >
> > > > > > > I agree that what you observe warrants further investigation,
> > not so
> > > > > much
> > > > > > > because these are clear performance regressions but because
> they
> > > > might
> > > > > be
> > > > > > > indications of underlying issues, as you noted. However, from a
> > major
> > > > > > > release standpoint I'd say that such preliminary evidence
> > probably
> > > > > falls
> > > > > > > within the range of acceptable differences in the presence of
> > major
> > > > > > changes
> > > > > > > and can be optimized over time in subsequent releases.
> > > > > > >
> > > > > > > Having said that, I'd take Israel's comment one step further
> and
> > say
> > > > > that
> > > > > > > in order to be able to give more definitive answers it'd be
> good
> > to
> > > > > have
> > > > > > a
> > > > > > > description of the setup that is reproducible. Briefly, that
> > would
> > > > > > include
> > > > > > > both the benchmark setup (specs etc) as well as the benchmark
> > suite
> > > > and
> > > > > > the
> > > > > > > way to run it (links to benchmark code including configurations
> > and
> > > > > > > description of how to run and reproduce).
> > > > > > >
> > > > > > > Small note that the attached plot is missing units on the
> x-axis
> > > > > (y-axis
> > > > > > I
> > > > > > > assume is millise

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

2021-09-08 Thread Apache Jenkins Server 
See 


Changes:


--
[...truncated 489421 lines...]
[2021-09-08T15:44:53.367Z] > Task :raft:testClasses UP-TO-DATE
[2021-09-08T15:44:53.367Z] > Task :connect:json:testJar
[2021-09-08T15:44:53.367Z] > Task :connect:json:testSrcJar
[2021-09-08T15:44:53.367Z] > Task :metadata:compileTestJava UP-TO-DATE
[2021-09-08T15:44:53.367Z] > Task :metadata:testClasses UP-TO-DATE
[2021-09-08T15:44:53.367Z] > Task 
:clients:generateMetadataFileForMavenJavaPublication
[2021-09-08T15:44:53.367Z] > Task 
:clients:generatePomFileForMavenJavaPublication
[2021-09-08T15:44:54.314Z] 
[2021-09-08T15:44:54.314Z] > Task :streams:processMessages
[2021-09-08T15:44:54.314Z] Execution optimizations have been disabled for task 
':streams:processMessages' to ensure correctness due to the following reasons:
[2021-09-08T15:44:54.314Z]   - Gradle detected a problem with the following 
location: 
'/home/jenkins/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.2/userguide/validation_problems.html#implicit_dependency
 for more details about this problem.
[2021-09-08T15:44:54.314Z] MessageGenerator: processed 1 Kafka message JSON 
files(s).
[2021-09-08T15:44:54.314Z] 
[2021-09-08T15:44:54.314Z] > Task :streams:compileJava UP-TO-DATE
[2021-09-08T15:44:54.314Z] > Task :streams:classes UP-TO-DATE
[2021-09-08T15:44:54.314Z] > Task :streams:test-utils:compileJava UP-TO-DATE
[2021-09-08T15:44:54.314Z] > Task :streams:copyDependantLibs
[2021-09-08T15:44:54.314Z] > Task :streams:jar UP-TO-DATE
[2021-09-08T15:44:54.314Z] > Task 
:streams:generateMetadataFileForMavenJavaPublication
[2021-09-08T15:44:58.365Z] > Task :connect:api:javadoc
[2021-09-08T15:44:58.365Z] > Task :connect:api:copyDependantLibs UP-TO-DATE
[2021-09-08T15:44:58.365Z] > Task :connect:api:jar UP-TO-DATE
[2021-09-08T15:44:58.365Z] > Task 
:connect:api:generateMetadataFileForMavenJavaPublication
[2021-09-08T15:44:59.313Z] > Task :connect:json:copyDependantLibs UP-TO-DATE
[2021-09-08T15:44:59.313Z] > Task :connect:json:jar UP-TO-DATE
[2021-09-08T15:44:59.313Z] > Task 
:connect:json:generateMetadataFileForMavenJavaPublication
[2021-09-08T15:44:59.313Z] > Task :connect:api:javadocJar
[2021-09-08T15:44:59.313Z] > Task :connect:api:compileTestJava UP-TO-DATE
[2021-09-08T15:44:59.313Z] > Task :connect:api:testClasses UP-TO-DATE
[2021-09-08T15:44:59.313Z] > Task :connect:api:testJar
[2021-09-08T15:44:59.313Z] > Task :connect:api:testSrcJar
[2021-09-08T15:44:59.313Z] > Task 
:connect:json:publishMavenJavaPublicationToMavenLocal
[2021-09-08T15:44:59.313Z] > Task :connect:json:publishToMavenLocal
[2021-09-08T15:44:59.313Z] > Task 
:connect:api:publishMavenJavaPublicationToMavenLocal
[2021-09-08T15:44:59.313Z] > Task :connect:api:publishToMavenLocal
[2021-09-08T15:45:03.108Z] > Task :streams:javadoc
[2021-09-08T15:45:03.108Z] > Task :streams:javadocJar
[2021-09-08T15:45:04.881Z] > Task :clients:javadoc
[2021-09-08T15:45:04.881Z] > Task :clients:javadocJar
[2021-09-08T15:45:05.830Z] 
[2021-09-08T15:45:05.830Z] > Task :clients:srcJar
[2021-09-08T15:45:05.830Z] Execution optimizations have been disabled for task 
':clients:srcJar' to ensure correctness due to the following reasons:
[2021-09-08T15:45:05.830Z]   - Gradle detected a problem with the following 
location: 
'/home/jenkins/workspace/Kafka_kafka_trunk/clients/src/generated/java'. Reason: 
Task ':clients:srcJar' uses this output of task ':clients: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.2/userguide/validation_problems.html#implicit_dependency
 for more details about this problem.
[2021-09-08T15:45:07.605Z] 
[2021-09-08T15:45:07.605Z] > Task :clients:testJar
[2021-09-08T15:45:07.605Z] > Task :clients:testSrcJar
[2021-09-08T15:45:07.605Z] > Task 
:clients:publishMavenJavaPublicationToMavenLocal
[2021-09-08T15:45:07.605Z] > Task :clients:publishToMavenLocal
[2021-09-08T15:45:24.006Z] > Task :core:compileScala
[2021-09-08T15:47:14.243Z] > Task :core:classes
[2021-09-08T15:47:14.243Z] > Task :core:compileTestJava NO-SOURCE
[2021-09-08T15:47:45.194Z] > Task :core:compileTestScala
[2021-09-08T15:49:34.726Z] > Task :core:testClasses
[2021-09-08T15:49:42.145Z] > Task :streams:compileTestJava
[2021-09-08T15:49:42.145Z] > Task :streams:testClasses
[2021-09-08T15:49:43.047Z] > Task :streams:testJar
[2021-09-08T15:49:43.996Z] > Task :streams:testSrcJar
[2021-09-08T15:49:43.996Z] > Task 
:streams:publishMavenJavaPublicationToMavenLocal
[20

[jira] [Created] (KAFKA-13278) Deserialization behavior of the Fetcher class does not match up with API contract of the Deserializer interface

2021-09-08 Thread Julian Reichinger (Jira) 
Julian Reichinger created KAFKA-13278:
-

 Summary: Deserialization behavior of the Fetcher class does not 
match up with API contract of the Deserializer interface
 Key: KAFKA-13278
 URL: https://issues.apache.org/jira/browse/KAFKA-13278
 Project: Kafka
  Issue Type: Bug
  Components: clients, documentation
Affects Versions: 2.6.0
Reporter: Julian Reichinger


The documentation of the
{noformat}
org.apache.kafka.common.serialization.Deserializer{noformat}
interface states that implementations have to expect null byte-arrays and 
should handle them in a meaningful way.

However, at least in the kafka client it seems to be impossible to actually get 
a null value into a deserializer because the class
{noformat}
org.apache.kafka.clients.consumer.internals.Fetcher{noformat}
does not call the registered deserializer in case of a null value.
{code:java}
private ConsumerRecord parseRecord(TopicPartition partition,
 RecordBatch batch,
 Record record) {
try {
long offset = record.offset();
long timestamp = record.timestamp();
Optional leaderEpoch = 
maybeLeaderEpoch(batch.partitionLeaderEpoch());
TimestampType timestampType = batch.timestampType();
Headers headers = new RecordHeaders(record.headers());
ByteBuffer keyBytes = record.key();
byte[] keyByteArray = keyBytes == null ? null : 
Utils.toArray(keyBytes);
K key = keyBytes == null ? null : 
this.keyDeserializer.deserialize(partition.topic(), headers, keyByteArray);
ByteBuffer valueBytes = record.value();
byte[] valueByteArray = valueBytes == null ? null : 
Utils.toArray(valueBytes);
V value = valueBytes == null ? null : 
this.valueDeserializer.deserialize(partition.topic(), headers, valueByteArray);
return new ConsumerRecord<>(partition.topic(), 
partition.partition(), offset,
timestamp, timestampType, 
record.checksumOrNull(),
keyByteArray == null ? 
ConsumerRecord.NULL_SIZE : keyByteArray.length,
valueByteArray == null ? 
ConsumerRecord.NULL_SIZE : valueByteArray.length,
key, value, headers, leaderEpoch);
} catch (RuntimeException e) {
throw new SerializationException("Error deserializing key/value for 
partition " + partition +
" at offset " + record.offset() + ". If needed, please seek 
past the record to continue consumption.", e);
}
}
{code}
I implemented an ErrorHandlingDeserializer which I use to wrap the actual 
deserializers and which records the result (value or exception) in a container 
object.
{code:java}
/**
 * Handles exceptions during de-serializations thrown by a delegate {@link 
Deserializer}.
 *
 * @param  type of the deserialized object
 */
final class ErrorHandlingDeserializer implements Deserializer> 
{

  private final Deserializer> delegate;

  private ErrorHandlingDeserializer(Deserializer> delegate) {
this.delegate = requireNonNull(delegate);
  }

  static  ErrorHandlingDeserializer wrap(Deserializer> 
delegate) {
return new ErrorHandlingDeserializer<>(delegate);
  }

  @Override
  public ReadResult deserialize(String topic, @Nullable byte[] data) {
try {
  return ReadResult.successful(delegate.deserialize(topic, data));
} catch (Exception e) {
  return ReadResult.failed(e);
}
  }
}
{code}
This deserializer cannot produce a null value. However, because of the Fetcher 
behavior I still have to check for null values in the consumer records at every 
usage and additionally I also have to check for a null value inside the 
ReadResult container class, because the Deserializer API says so and I have no 
guarantee that the Fetcher behavior will never change.

In my opinion this behavior is a bug, because everyone implementing a 
Deserializer would expect to actually receive null values (for example in case 
of deletions). There should either be a guarantee on the client side that 
Deserializers always receive null values or that they never receive null values.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[GitHub] [kafka-site] miguno commented on a change in pull request #371: Added select KS APAC & EU 2021 videos

2021-09-08 Thread GitBox 


miguno commented on a change in pull request #371:
URL: https://github.com/apache/kafka-site/pull/371#discussion_r704422376



##
File path: videos.html
##
@@ -33,6 +33,22 @@ 
   
 
   
+
+  https://www.confluent.io/events/kafka-summit-europe-2021/making-kafka-cloud-native/";>Making
 Kafka Cloud Native,
+  Jay Kreps (Confluent), KS EU 2021
+
+
+  https://www.confluent.io/events/kafka-summit-europe-2021/how-ksqldb-works/";>How
 ksqlDB works,
+  Michael Drogalis (Confluent) , KS EU 2021

Review comment:
   ```suggestion
 Michael Drogalis (Confluent), KS EU 2021
   ```

##
File path: videos.html
##
@@ -125,6 +141,22 @@ 
   
 
   
+
+  https://www.confluent.io/events/kafka-summit-apac-2021/should-you-read-kafka-as-a-stream-or-in-batch-should-you-even-care/";>Should
 You Read Kafka as a Stream or in Batch? Should You Even Care?,
+  Ido Nadler (Nielsen) & Opher Dubrovsky (Nielsen) 
+
+
+  https://www.confluent.io/events/kafka-summit-apac-2021/scaling-a-core-banking-engine-using-apache-kafka/";>Scaling
 a Core Banking Engine Using Apache Kafka,
+  Peter Dudbridge (Thought Machine)

Review comment:
   Lacks conference info (which summit?)




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@kafka.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Resolved] (KAFKA-12857) Using Connect Sink with CooperativeStickyAssignor results in commit offsets failure

2021-09-08 Thread Chris Egerton (Jira) 


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

Chris Egerton resolved KAFKA-12857.
---
  Assignee: (was: dgd_contributor)
Resolution: Duplicate

> Using Connect Sink with CooperativeStickyAssignor results in commit offsets 
> failure
> ---
>
> Key: KAFKA-12857
> URL: https://issues.apache.org/jira/browse/KAFKA-12857
> Project: Kafka
>  Issue Type: Bug
>  Components: KafkaConnect
>Affects Versions: 2.7.1
> Environment: Linux
>Reporter: Oliver Hsu
>Priority: Major
>
> We are attempting to use a Kafka Connect Sink Connector with 
> {{CooperativeStickyAssignor}} assignment strategy.  When we use 
> {{CooperativeStickyAssignor}} offset commits sometimes fail with 
> {{[2021-05-26 22:03:36,435] WARN WorkerSinkTask\{id=sink-connector-7} 
> Ignoring invalid task provided offset 
> mytopic-0/OffsetAndMetadata\{offset=16305575, leaderEpoch=null, metadata=''} 
> – partition not assigned, assignment=[mytopic-0] 
> (org.apache.kafka.connect.runtime.WorkerSinkTask:434)}}
> Note that the invalid partition in the warning message matches the partition 
> assignment.
> *Config changes*
> {{consumer.partition.assignment.strategy=org.apache.kafka.clients.consumer.CooperativeStickyAssignor}}
> *Cooperative vs Eager Assignment Strategy background*
>  
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-429%3A+Kafka+Consumer+Incremental+Rebalance+Protocol#KIP429:KafkaConsumerIncrementalRebalanceProtocol-ConsumerRebalanceListenerandConsumerPartitionAssignorSemantics]
> With eager assignment:
> {quote}Listener#onPartitionsAssigned: called on the full set of assigned 
> partitions (may have overlap with the partitions passed to 
> #onPartitionsRevoked
> {quote}
> With cooperative assignment:
> {quote}Listener#onPartitionsAssigned: called on the subset of assigned 
> partitions that were not previously owned before this rebalance. There should 
> be no overlap with the revoked partitions (if any). This will always be 
> called, even if there are no new partitions being assigned to a given member.
> {quote}
> This means with cooperative assignment, `onPartitionsAssigned` may be called 
> with a partial assignment or an empty collection.
> However, the 
> [WorkerSinkTask.HandleRebalance|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerSinkTask.java#L669-L680]
>  class makes the assumption that `onPartitionsAssigned` is called with the 
> full set of assigned partitions which is true for eager but not coooperative.
> {code:java|title=WorkerSinkTask.HandleRebalance.java|borderStyle=solid}
> public void onPartitionsAssigned(Collection 
> partitions) {
> log.debug("{} Partitions assigned {}", WorkerSinkTask.this, 
> partitions);
> lastCommittedOffsets = new HashMap<>();
> currentOffsets = new HashMap<>();
> for (TopicPartition tp : partitions) {
> long pos = consumer.position(tp);
> lastCommittedOffsets.put(tp, new OffsetAndMetadata(pos));
> currentOffsets.put(tp, new OffsetAndMetadata(pos));
> log.debug("{} Assigned topic partition {} with offset {}", 
> WorkerSinkTask.this, tp, pos);
> }
> {code}
> The {{onPartitionsAssigned}} creates a new empty {{HashMap}} and puts the 
> offsets of the {{partitions}} in that {{HashMap}}.
> In the logs we see
>  {{[2021-05-26 22:02:09,785] DEBUG WorkerSinkTask\{id=sink-connector-7} 
> Partitions assigned [myTopic-0] 
> (org.apache.kafka.connect.runtime.WorkerSinkTask:677)}}
>  {{[2021-05-26 22:02:13,063] DEBUG WorkerSinkTask\{id=sink-connector-7} 
> Partitions assigned [] (org.apache.kafka.connect.runtime.WorkerSinkTask:677)}}
>  {{[2021-05-26 22:02:16,074] DEBUG WorkerSinkTask\{id=sink-connector-7} }} 
> Partitions assigned [] (org.apache.kafka.connect.runtime.WorkerSinkTask:677)}}
> These logs show that the {{CooperativeStickyAssignor}} calls 
> {{onPartitionsAssigned}} first with the partition assigned to it followed by 
> additional calls with an empty {{partitions}} collection.
> When {{HandleRebalance.onPartitionsAssigned}} is called first with the 
> assigned partition followed by empty collections, the result will be 
> {{lastCommittedOffsets}} initialized to an empty {{HashMap}}.
> Inside 
> [WorkerSinkTask.commitOffsets|https://github.com/apache/kafka/blob/trunk/connect/runtime/src/main/java/org/apache/kafka/connect/runtime/WorkerSinkTask.java#L415-L419],
>  the current {{committableOffsets}} are based on the 
> {{lastCommittedOffsets}}, which is an empty {{HashMap}}:
> {code:java|title=WorkerSinkTask.java|borderStyle=solid}
> private void commitOffsets(long now, boolean closing) {
> ...
>

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 2.8 #77

2021-09-08 Thread Apache Jenkins Server 
See

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #127

2021-09-08 Thread Apache Jenkins Server 
See

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

2021-09-08 Thread Apache Jenkins Server 
See

Build failed in Jenkins: Kafka » kafka-2.7-jdk8 #177

2021-09-08 Thread Apache Jenkins Server 
See 


Changes:

[rajinisivaram] KAFKA-13277; Fix size calculation for tagged string fields in 
message generator (#11308)


--
[...truncated 3.46 MB...]

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentWithNullReversForCompareKeyValueWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueIsEqualWithNullForCompareKeyValueWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfKeyAndValueIsEqualWithNullForCompareKeyValueWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfKeyIsDifferentWithNullForCompareKeyValueTimestampWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueAndTimestampIsEqualForCompareValueTimestampWithProducerRecord 
STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldPassIfValueAndTimestampIsEqualForCompareValueTimestampWithProducerRecord 
PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestamp STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReversForCompareKeyValueTimestamp PASSED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestampWithProducerRecord
 STARTED

org.apache.kafka.streams.test.OutputVerifierTest > 
shouldFailIfValueIsDifferentWithNullReverseForCompareValueTimestampWithProducerRecord
 PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldReturnIsOpen 
STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldReturnIsOpen 
PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldReturnName 
STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldReturnName 
PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldPutWithUnknownTimestamp STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldPutWithUnknownTimestamp PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldPutWindowStartTimestampWithUnknownTimestamp STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldPutWindowStartTimestampWithUnknownTimestamp PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldReturnIsPersistent STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldReturnIsPersistent PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldForwardDeprecatedInit STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > 
shouldForwardDeprecatedInit PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardClose 
STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardClose 
PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardFlush 
STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardFlush 
PASSED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardInit 
STARTED

org.apache.kafka.streams.internals.WindowStoreFacadeTest > shouldForwardInit 
PASSED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldStoreAndReturnStateStores STARTED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldStoreAndReturnStateStores PASSED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldCaptureOutputRecordsUsingTo STARTED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldCaptureOutputRecordsUsingTo PASSED

org.apache.kafka.streams.MockProcessorContextTest > shouldCaptureOutputRecords 
STARTED

org.apache.kafka.streams.MockProcessorContextTest > shouldCaptureOutputRecords 
PASSED

org.apache.kafka.streams.MockProcessorContextTest > 
fullConstructorShouldSetAllExpectedAttributes STARTED

org.apache.kafka.streams.MockProcessorContextTest > 
fullConstructorShouldSetAllExpectedAttributes PASSED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldCaptureCommitsAndAllowReset STARTED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldCaptureCommitsAndAllowReset PASSED

org.apache.kafka.streams.MockProcessorContextTest > 
shouldThrowIfForwardedWithDeprecatedChildName STARTED

org.apache.kafka.streams.MockProcessorContextTest > 
sho

[jira] [Reopened] (KAFKA-13128) Flaky Test StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread

2021-09-08 Thread Josep Prat (Jira) 


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

Josep Prat reopened KAFKA-13128:


Sorry to reopen this issue, it just occurred in this PR 
[https://github.com/apache/kafka/pull/11302]

It's a different error though:

{{}}
{code:java}
java.lang.AssertionError: Unexpected exception thrown while getting the value 
from store.
Expected: is (a string containing "Cannot get state store source-table because 
the stream thread is PARTITIONS_ASSIGNED, not RUNNING" or a string containing 
"The state store, source-table, may have migrated to another instance" or a 
string containing "Cannot get state store source-table because the stream 
thread is STARTING, not RUNNING")
  but: was "Cannot get state store source-table because the stream thread is 
PARTITIONS_REVOKED, not RUNNING"{code}
[https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-11302/3/testReport/junit/org.apache.kafka.streams.integration/StoreQueryIntegrationTest/Build___JDK_8_and_Scala_2_12___shouldQueryStoresAfterAddingAndRemovingStreamThread/?cloudbees-analytics-link=scm-reporting%2Ftests%2Ffailed]

Let me know if I should have opened a new issue instead of reopening this one.

{{}}

> Flaky Test 
> StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread
> 
>
> Key: KAFKA-13128
> URL: https://issues.apache.org/jira/browse/KAFKA-13128
> Project: Kafka
>  Issue Type: Bug
>  Components: streams
>Affects Versions: 3.0.0, 2.8.1
>Reporter: A. Sophie Blee-Goldman
>Assignee: Walker Carlson
>Priority: Blocker
>  Labels: flaky-test
> Fix For: 3.1.0
>
>
> h3. Stacktrace
> java.lang.AssertionError: Expected: is not null but: was null 
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) 
>   at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
>   at 
> org.apache.kafka.streams.integration.StoreQueryIntegrationTest.lambda$shouldQueryStoresAfterAddingAndRemovingStreamThread$19(StoreQueryIntegrationTest.java:461)
>   at 
> org.apache.kafka.streams.integration.StoreQueryIntegrationTest.until(StoreQueryIntegrationTest.java:506)
>   at 
> org.apache.kafka.streams.integration.StoreQueryIntegrationTest.shouldQueryStoresAfterAddingAndRemovingStreamThread(StoreQueryIntegrationTest.java:455)
>  
> https://ci-builds.apache.org/job/Kafka/job/kafka-pr/job/PR-11085/5/testReport/org.apache.kafka.streams.integration/StoreQueryIntegrationTest/Build___JDK_16_and_Scala_2_13___shouldQueryStoresAfterAddingAndRemovingStreamThread_2/



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Jenkins build is unstable: Kafka » Kafka Branch Builder » 2.8 #76

2021-09-08 Thread Apache Jenkins Server 
See

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.0 #126

2021-09-08 Thread Apache Jenkins Server 
See

Re: [DISCUSS] KIP-763: Range queries with open endpoints

2021-09-08 Thread Patrick Stuedi 
Boyang,

Thanks for your comment. The concern about whether a null-based approach
increases the chances of hidden bugs is a valid concern. In the end, the
decision to go with this approach was guided by considering the effort and
implications of changing the API towards a new range interface, versus the
likelihood of such bugs happening. Changing an API is always a
major effort. On other hand, I think the risk of hidden bugs with the
null-based API are low, for two reasons. First, there should not be any
existing application developed for the old API passing null, as null
parameters did throw an exception in the old API. New applications passing
null without the intention to do an open endpoint range query are, I would
say, unlikely, and if they happen then it's clearly the application
developer's mistake who did not read the API documentation.

-Patrick

On Sat, Aug 28, 2021 at 8:24 AM Boyang Chen 
wrote:

> Thanks Patrick for the KIP and sorry for being late to the party here. One
> thing I would like to understand is, what's the expected behavior when a
> user specifies a null key in previous versions? In the new version which
> uses null key for open-ended range queries, could it potentially hide bugs
> in the user's code when their intention was to do a bounded range query but
> accidentally set the key to null?
>
> Boyang
>
> On Wed, Jul 21, 2021 at 2:59 AM Patrick Stuedi
> 
> wrote:
>
> > Thanks John, Bruno for the valuable feedback!
> >
> > John: I had a quick look at the SessionStore and WindowStore interface.
> > While it looks like we should be able to apply similar ideas to those
> > stores, the actual interfaces are slightly different and expanding them
> for
> > open ranges may need a bit more thinking. In that sense, and to make sure
> > we will be converging with this KIP, I'd prefer to not expand the scope
> of
> > the KIP . As Bruno suggested we can always propose changes to the
> > SessionStore and WindowStore in a separate KIP. I'll add a subsection in
> > the rejected alternatives.
> >
> > @Bruno: good point, I'll add an example. Yes, all() will be equivalent to
> > range(null, null) and the implementation of all() will be a call to
> > range(null, null).
> >
> > -Patrick
> >
> > On Wed, Jul 21, 2021 at 9:12 AM Bruno Cadonna 
> wrote:
> >
> > > Thanks for the KIP, Patrick!
> > >
> > > I agree with John that your KIP is well motivated.
> > >
> > > I have just one minor feedback. Could you add store.range(null, null)
> to
> > > the example snippets with the comment that this is equivalent to all()
> > > (it is equivalent, right?)? This question about equivalence between
> > > range(null, null) and all() came up in my mind when I read the KIP and
> I
> > > think I am not the only one.
> > >
> > > Regarding expanding the KIP to SessionStore and WindowStore, I think
> you
> > > should not expand scope of the KIP. We can do the changes to the
> > > SessionStore and WindowStore in a separate KIP. But it is your call!
> > >
> > >
> > > Best,
> > > Bruno
> > >
> > > On 21.07.21 00:18, John Roesler wrote:
> > > > Thanks for the KIP, Patrick!
> > > >
> > > > I think your KIP is well motivated. It's definitely a bummer
> > > > to have to iterate over the full store as a workaround for
> > > > open-ended ranges.
> > > >
> > > > I agree with your pragmatic approach here. We have recently
> > > > had a couple of other contributions to the store APIs
> > > > (prefix and reverseRange), and the complexity of adding
> > > > those new methods far exceeded what anyone expected. I'd be
> > > > in favor of being conservative with new store APIs until we
> > > > are able to reign in that complexity somehow. Since your
> > > > proposed semantics seem reasonable, I'm in favor.
> > > >
> > > > While reviewing your KIP, it struck me that we have several
> > > > range-like APIs on:
> > > > * SessionStore
> > > > (
> > >
> >
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/ReadOnlySessionStore.java
> > > )
> > > > * WindowStore
> > > > (
> > >
> >
> https://github.com/apache/kafka/blob/trunk/streams/src/main/java/org/apache/kafka/streams/state/ReadOnlyWindowStore.java
> > > )
> > > > as well.
> > > >
> > > > Do you think it would be a good idea to also propose a
> > > > similar change on those APIs? It might be nice (for exactly
> > > > the same reasons you documented), but it also increases the
> > > > scope of your work. There is one extra wrinkle I can see:
> > > > SessionStore has versions of the range methods that take a
> > > > `long` instead of an `Instant`, so `null` wouldn't work for
> > > > them.
> > > >
> > > > If you prefer to keep your KIP narrow in scope to just the
> > > > KeyValueStore, I'd also support you. In that case, it might
> > > > be a good idea to simply mention in the "Rejected
> > > > Alternatives" that you decided not to address those other
> > > > store APIs at this time. That way, people later on won't
> > > > have to wonder why those ot

Re: [VOTE] KIP-770: Replace "buffered.records.per.partition" with "input.buffer.max.bytes"

2021-09-08 Thread Luke Chen 
Thanks for the KIP.

+ 1 (non-binding)

Thanks.
Luke

On Wed, Sep 8, 2021 at 2:48 PM Josep Prat 
wrote:

> +1 (non binding).
>
> Thanks for the KIP Sagar!
> ———
> Josep Prat
>
> Aiven Deutschland GmbH
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> m: +491715557497
>
> w: aiven.io
>
> e: josep.p...@aiven.io
>
> On Wed, Sep 8, 2021, 03:29 Sophie Blee-Goldman  >
> wrote:
>
> > +1 (binding)
> >
> > Thanks for the KIP!
> >
> > -Sophie
> >
> > On Tue, Sep 7, 2021 at 1:59 PM Guozhang Wang  wrote:
> >
> > > Thanks Sagar, +1 from me.
> > >
> > >
> > > Guozhang
> > >
> > > On Sat, Sep 4, 2021 at 10:29 AM Sagar 
> wrote:
> > >
> > > > Hi All,
> > > >
> > > > I would like to start a vote on the following KIP:
> > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=186878390
> > > >
> > > > Thanks!
> > > > Sagar.
> > > >
> > >
> > >
> > > --
> > > -- Guozhang
> > >
> >
>