Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.6 #8

[Apache Jenkins Server]

See 

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 305104 lines...]

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldKeepAddedTasks() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsForUnassignedTasks() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsForUnassignedTasks() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignLockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignLockingTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignLockingTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeStreamTimePunctuated() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeStreamTimePunctuated() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateEmptyWriteBatches() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateEmptyWriteBatches() 
PASSED

Gradle Test Run :streams:test > 

[jira] [Resolved] (KAFKA-15183) Add more controller, loader, snapshot emitter metrics

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-15183.
--
Fix Version/s: 3.6.0
 Assignee: Colin McCabe
   Resolution: Fixed

Most of the KIP-938 metrics are now implemented for 3.6. The exception is the 
ForwardingManager metrics, which will have to wait until 3.7.

> Add more controller, loader, snapshot emitter metrics
> -
>
> Key: KAFKA-15183
> URL: https://issues.apache.org/jira/browse/KAFKA-15183
> Project: Kafka
>  Issue Type: Improvement
>Reporter: Colin McCabe
>Assignee: Colin McCabe
>Priority: Major
> Fix For: 3.6.0
>
>
> Add the controller, loader, and snapshot emitter metrics from KIP-938.



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

[jira] [Created] (KAFKA-15406) Add the ForwardingManager metrics from KIP-938

[Colin McCabe (Jira)]

Colin McCabe created KAFKA-15406:


 Summary: Add the ForwardingManager metrics from KIP-938
 Key: KAFKA-15406
 URL: https://issues.apache.org/jira/browse/KAFKA-15406
 Project: Kafka
  Issue Type: Improvement
Affects Versions: 3.7.0
Reporter: Colin McCabe






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

[jira] [Resolved] (KAFKA-14305) KRaft Metadata Transactions

[Colin McCabe (Jira)]

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

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

> KRaft Metadata Transactions
> ---
>
> Key: KAFKA-14305
> URL: https://issues.apache.org/jira/browse/KAFKA-14305
> Project: Kafka
>  Issue Type: New Feature
>Reporter: David Arthur
>Assignee: Colin McCabe
>Priority: Major
> Fix For: 3.6.0
>
>
> [https://cwiki.apache.org/confluence/display/KAFKA/KIP-868+Metadata+Transactions]



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

[jira] [Resolved] (KAFKA-15374) ZK migration fails on configs for default broker resource

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-15374.
--
  Assignee: David Arthur
Resolution: Fixed

> ZK migration fails on configs for default broker resource
> -
>
> Key: KAFKA-15374
> URL: https://issues.apache.org/jira/browse/KAFKA-15374
> Project: Kafka
>  Issue Type: Bug
>Affects Versions: 3.5.1
>Reporter: David Arthur
>Assignee: David Arthur
>Priority: Critical
> Fix For: 3.6.0, 3.5.2
>
>
> This error was seen while performing a ZK to KRaft migration on a cluster 
> with configs for the default broker resource
>  
> {code:java}
> java.lang.NumberFormatException: For input string: ""
>   at 
> java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:67)
>   at java.base/java.lang.Integer.parseInt(Integer.java:678)
>   at java.base/java.lang.Integer.valueOf(Integer.java:999)
>   at 
> kafka.zk.ZkMigrationClient.$anonfun$migrateBrokerConfigs$2(ZkMigrationClient.scala:371)
>   at 
> kafka.zk.migration.ZkConfigMigrationClient.$anonfun$iterateBrokerConfigs$1(ZkConfigMigrationClient.scala:174)
>   at 
> kafka.zk.migration.ZkConfigMigrationClient.$anonfun$iterateBrokerConfigs$1$adapted(ZkConfigMigrationClient.scala:156)
>   at 
> scala.collection.immutable.BitmapIndexedMapNode.foreach(HashMap.scala:1076)
>   at scala.collection.immutable.HashMap.foreach(HashMap.scala:1083)
>   at 
> kafka.zk.migration.ZkConfigMigrationClient.iterateBrokerConfigs(ZkConfigMigrationClient.scala:156)
>   at 
> kafka.zk.ZkMigrationClient.migrateBrokerConfigs(ZkMigrationClient.scala:370)
>   at 
> kafka.zk.ZkMigrationClient.cleanAndMigrateAllMetadata(ZkMigrationClient.scala:530)
>   at 
> org.apache.kafka.metadata.migration.KRaftMigrationDriver$MigrateMetadataEvent.run(KRaftMigrationDriver.java:618)
>   at 
> org.apache.kafka.queue.KafkaEventQueue$EventContext.run(KafkaEventQueue.java:127)
>   at 
> org.apache.kafka.queue.KafkaEventQueue$EventHandler.handleEvents(KafkaEventQueue.java:210)
>   at 
> org.apache.kafka.queue.KafkaEventQueue$EventHandler.run(KafkaEventQueue.java:181)
>   at java.base/java.lang.Thread.run(Thread.java:833)
>   at org.apache.kafka.common.utils.KafkaThread.run(KafkaThread.java:64) 
> {code}
>  
> This is due to not considering the default resource type when we collect the 
> broker IDs in ZkMigrationClient#migrateBrokerConfigs.
>  
>  



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

[jira] [Resolved] (KAFKA-14984) DynamicBrokerReconfigurationTest.testThreadPoolResize() test is flaky

[Justine Olshan (Jira)]

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

Justine Olshan resolved KAFKA-14984.

Resolution: Duplicate

> DynamicBrokerReconfigurationTest.testThreadPoolResize() test is flaky 
> --
>
> Key: KAFKA-14984
> URL: https://issues.apache.org/jira/browse/KAFKA-14984
> Project: Kafka
>  Issue Type: Test
>Reporter: Manyanda Chitimbo
>Priority: Major
>  Labels: flaky-test
>
> The test sometimes fails with the below log 
> {code:java}
> kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize() failed, 
> log available in 
> .../core/build/reports/testOutput/kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize().test.stdoutGradle
>  Test Run :core:test > Gradle Test Executor 6 > 
> DynamicBrokerReconfigurationTest > testThreadPoolResize() FAILED
>     org.opentest4j.AssertionFailedError: Invalid threads: expected 6, got 8: 
> List(data-plane-kafka-socket-acceptor-ListenerName(PLAINTEXT)-PLAINTEXT-0, 
> data-plane-kafka-socket-acceptor-ListenerName(PLAINTEXT)-PLAINTEXT-0, 
> data-plane-kafka-socket-acceptor-ListenerName(INTERNAL)-SSL-0, 
> data-plane-kafka-socket-acceptor-ListenerName(EXTERNAL)-SASL_SSL-0, 
> data-plane-kafka-socket-acceptor-ListenerName(INTERNAL)-SSL-0, 
> data-plane-kafka-socket-acceptor-ListenerName(INTERNAL)-SSL-0, 
> data-plane-kafka-socket-acceptor-ListenerName(EXTERNAL)-SASL_SSL-0, 
> data-plane-kafka-socket-acceptor-ListenerName(EXTERNAL)-SASL_SSL-0) ==> 
> expected:  but was: 
>         at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
>         at 
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
>         at 
> app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
>         at 
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
>         at 
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:211)
>         at 
> app//kafka.server.DynamicBrokerReconfigurationTest.verifyThreads(DynamicBrokerReconfigurationTest.scala:1634)
>         at 
> app//kafka.server.DynamicBrokerReconfigurationTest.testThreadPoolResize(DynamicBrokerReconfigurationTest.scala:872)
>  {code}



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

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 306122 lines...]

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsNullButExistingCacheIsNotNull() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsNullButExistingCacheIsNotNull() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfStatisticsToAddIsNotNullButExistingStatisticsAreNull() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfStatisticsToAddIsNotNullButExistingStatisticsAreNull() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsNotSameAsAllExistingCaches() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsNotSameAsAllExistingCaches() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldNotRecordStatisticsBasedMetricsIfStatisticsIsNull() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldNotRecordStatisticsBasedMetricsIfStatisticsIsNull() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldSetStatsLevelToExceptDetailedTimersWhenValueProvidersWithStatisticsAreAdded()
 STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldSetStatsLevelToExceptDetailedTimersWhenValueProvidersWithStatisticsAreAdded()
 PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldRecordStatisticsBasedMetrics() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldRecordStatisticsBasedMetrics() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfMetricRecorderIsReInitialisedWithDifferentStreamsMetrics() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfMetricRecorderIsReInitialisedWithDifferentStreamsMetrics() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldInitMetricsRecorder() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldInitMetricsRecorder() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfMetricRecorderIsReInitialisedWithDifferentTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfMetricRecorderIsReInitialisedWithDifferentTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldCorrectlyHandleAvgRecordingsWithZeroSumAndCount() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldCorrectlyHandleAvgRecordingsWithZeroSumAndCount() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfStatisticsToAddIsNullButExistingStatisticsAreNotNull() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfStatisticsToAddIsNullButExistingStatisticsAreNotNull() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldNotAddItselfToRecordingTriggerWhenNotEmpty() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldNotAddItselfToRecordingTriggerWhenNotEmpty() 
PASSED
streams-1: SMOKE-TEST-CLIENT-CLOSED
streams-0: SMOKE-TEST-CLIENT-CLOSED
streams-4: SMOKE-TEST-CLIENT-CLOSED
streams-1: SMOKE-TEST-CLIENT-CLOSED
streams-4: SMOKE-TEST-CLIENT-CLOSED
streams-3: SMOKE-TEST-CLIENT-CLOSED
streams-6: SMOKE-TEST-CLIENT-CLOSED
streams-5: SMOKE-TEST-CLIENT-CLOSED
streams-2: SMOKE-TEST-CLIENT-CLOSED
streams-3: SMOKE-TEST-CLIENT-CLOSED
streams-5: SMOKE-TEST-CLIENT-CLOSED
streams-0: SMOKE-TEST-CLIENT-CLOSED
streams-2: SMOKE-TEST-CLIENT-CLOSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfDbToAddWasAlreadyAddedForOtherSegment() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfDbToAddWasAlreadyAddedForOtherSegment() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldAddItselfToRecordingTriggerWhenFirstValueProvidersAreAddedAfterLastValueProvidersWereRemoved()
 STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 

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

[Apache Jenkins Server]

See 

Re: [DISCUSS] KIP-714: Client metrics and observability

[Andrew Schofield]

Hi Tom,
Thanks for your comments. Sorry for the delay in responding. They’re still 
useful
comments in spite of the fact that the voting has begun.

1) This is a good idea. I expect the client will emit the client instance ID
as a log line.

2) I will add PROXY protocol support to the future work. I agree.

3) Thanks for the suggestion.

4) Yes, the client authenticates before it can send any of the RPCs in this KIP.

5) a) Yes, a rogue client could in principle send metrics to all brokers 
resulting
in a lot of data being exported to the back end. Of course, a proper deployment
of a client telemetry reporter plugin would be instrumented to help the operator
diagnose this situation.

b) There are already instances of the client sending compressed data to
the broker. I think it is prudent to limit the maximum metrics payload size.
I will update the KIP accordingly.

6) Yes, bundling and relocating.

7) I will add a broker metric to help with diagnosis.

8) I will add some clarifying text. If the broker does not have a configured
metrics reporter that supports the new interface, it should not push metrics
and will not receive a metrics subscription. I am thinking over the options for
achieving this cleanly and will update the KIP.

Thanks for your interest in the KIP.

Thanks,
Andrew

> On 11 Aug 2023, at 09:48, Tom Bentley  wrote:
>
> Hi Andrew,
>
> Thanks for picking this KIP up. I know you've started a vote, so these are
> unhelpfully late... sorry about that, but hopefully they're still useful.
>
> 1. "The Kafka Java client provides an API for the application to read the
> generated client instance id to assist in mapping and identification of the
> client based on the collected metrics." In the multi-client, single-process
> model perhaps it would be desirable to have the option of including this in
> log messages emitted by the client library.
>
> 2. "Mapping the client instance id to an actual application instance
> running on a (virtual) machine can be done by inspecting the metrics
> resource labels, such as the client source address and source port, or
> security principal, all of which are added by the receiving broker." The
> specific example of correlation given here (source IP address) is
> problematic in environments where there may be network proxies (e.g.
> Kubernetes ingress) on the path between client and broker: The broker sees
> the IP address of the proxy. This is a rough edge which could be smoothed
> out if Kafka supported the PROXY protocol[1] which seems to have become
> something of a defacto standard. I'm not suggesting this need to be part of
> the KIP, but perhaps it could be added to Future Work?
> [1]: http://www.haproxy.org/download/2.9/doc/proxy-protocol.txt
>
> 3. Compression... just an idle idea, but I wonder if a useful further
> improvement in compression ratio could be achieve using zstd's support for
> dictionary compression[2]. I.e. a client could initially use training mode
> when sending metrics, but eventually include a dictionary to be used for
> subsequent metric sends. It's probably not worth the effort (at least for
> the initial implementation), but since you've gone to the effort of
> providing some numbers anyway, maybe it's not much additional effort to at
> least find out whether this makes a useful difference.
> [2]: http://facebook.github.io/zstd/#small-data
>
> 4. Maybe I didn't spot it, but I assume the initial
> GetTelemetrySubscriptionsRequest
> happens after authentication?
>
> 5. Rogue clients -- There are some interesting things to consider if we're
> trying to defend against a genuinely adversarial client.
>
> a) Client sends profiling information to all brokers at the maximum rate.
> Each broker forwards to the time series DB. Obviously this scales linearly
> with number of brokers, but it's clear that the load on the tsdb could be
> many times larger than users might expect.
> b) Client sends crafted compressed data which decompresses to require more
> memory that the broker can allocate.
>
> 6. Shadowing the OLTP and protobuf jars -- to be clear by this you mean
> both bundling _and_ relocating?
>
> 7. "In case the cluster load induced from metrics requests becomes
> unmanageable the remedy is to temporarily remove or limit configured
> metrics subscriptions.  " How would a user know that the observed load was
> due to handling metrics requests?
>
> 8. If I understand correctly, when the configured metrics reporter does not
> implement the new interface the client would still follow the described
> protocol only to have nowhere to send the metrics. Am I overlooking
> something?
>
> Thanks again,
>
> Tom
>
> On Fri, 11 Aug 2023 at 07:52, Andrew Schofield <
> andrew_schofield_j...@outlook.com> wrote:
>
>> Hi Doguscan,
>> Thanks for your question.
>>
>> If the target broker is unreachable, the client can send the metrics to
>> another
>> broker. It can select any of the other brokers for this purpose. What I
>> expect in
>> practice is that it 

Re: What are the biggest issues with Apache Kafka?

[Arpit Goyal]

Thanks Philip
Thanks and Regards
Arpit Goyal
8861094754


On Sat, Aug 26, 2023 at 12:03 AM Philip Nee  wrote:

> Hi Arpit: Here's a good starting point for Kraft-related issues:
>
> https://issues.apache.org/jira/browse/KAFKA-15401?jql=project%20%3D%20KAFKA%20AND%20component%20in%20(core%2C%20kraft)
>
> The recent Jenkin's builds have also been extremely flaky - This greatly
> impacts productivity.  This would also be an important area to work on.
> See here:
>
> https://issues.apache.org/jira/browse/KAFKA-15378?jql=project%20%3D%20KAFKA%20AND%20component%20in%20(%22system%20tests%22%2C%20%22unit%20tests%22)
>
> On Fri, Aug 25, 2023 at 11:28 AM Arpit Goyal 
> wrote:
>
> > Hi Colin,
> > Is there a ticket open for the same ?
> >
> > On Fri, Aug 25, 2023, 22:21 Colin McCabe  wrote:
> >
> > > If you want to get more familiar with the code base, one great way is
> to
> > > convert more integration tests to KRaft mode.
> > >
> > > :)
> > >
> > > best,
> > > Colin
> > >
> > > On Thu, Aug 10, 2023, at 17:16, Liam Hodges wrote:
> > > > I'm working with a small team of engineers looking to contribute to
> the
> > > > open source tools for Apache Kafka. What is missing in the Kafka
> > > community
> > > > right now? Are there any problems an open source project could solve
> > for
> > > > it's developers? Appreciate all feedback.
> > >
> >
>

Re: What are the biggest issues with Apache Kafka?

[Philip Nee]

Hi Arpit: Here's a good starting point for Kraft-related issues:
https://issues.apache.org/jira/browse/KAFKA-15401?jql=project%20%3D%20KAFKA%20AND%20component%20in%20(core%2C%20kraft)

The recent Jenkin's builds have also been extremely flaky - This greatly
impacts productivity.  This would also be an important area to work on.
See here:
https://issues.apache.org/jira/browse/KAFKA-15378?jql=project%20%3D%20KAFKA%20AND%20component%20in%20(%22system%20tests%22%2C%20%22unit%20tests%22)

On Fri, Aug 25, 2023 at 11:28 AM Arpit Goyal 
wrote:

> Hi Colin,
> Is there a ticket open for the same ?
>
> On Fri, Aug 25, 2023, 22:21 Colin McCabe  wrote:
>
> > If you want to get more familiar with the code base, one great way is to
> > convert more integration tests to KRaft mode.
> >
> > :)
> >
> > best,
> > Colin
> >
> > On Thu, Aug 10, 2023, at 17:16, Liam Hodges wrote:
> > > I'm working with a small team of engineers looking to contribute to the
> > > open source tools for Apache Kafka. What is missing in the Kafka
> > community
> > > right now? Are there any problems an open source project could solve
> for
> > > it's developers? Appreciate all feedback.
> >
>

Re: What are the biggest issues with Apache Kafka?

[Arpit Goyal]

Hi Colin,
Is there a ticket open for the same ?

On Fri, Aug 25, 2023, 22:21 Colin McCabe  wrote:

> If you want to get more familiar with the code base, one great way is to
> convert more integration tests to KRaft mode.
>
> :)
>
> best,
> Colin
>
> On Thu, Aug 10, 2023, at 17:16, Liam Hodges wrote:
> > I'm working with a small team of engineers looking to contribute to the
> > open source tools for Apache Kafka. What is missing in the Kafka
> community
> > right now? Are there any problems an open source project could solve for
> > it's developers? Appreciate all feedback.
>

[jira] [Resolved] (KAFKA-15389) MetadataLoader may publish an empty image on first start

[Colin McCabe (Jira)]

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

Colin McCabe resolved KAFKA-15389.
--
Fix Version/s: 3.6.0
   Resolution: Fixed

> MetadataLoader may publish an empty image on first start
> 
>
> Key: KAFKA-15389
> URL: https://issues.apache.org/jira/browse/KAFKA-15389
> Project: Kafka
>  Issue Type: Bug
>Reporter: David Arthur
>Assignee: David Arthur
>Priority: Minor
> Fix For: 3.6.0
>
>
> When first loading from an empty log, there is a case where MetadataLoader 
> can publish an image before the bootstrap records are processed. This isn't 
> exactly incorrect, since all components implicitly start from the empty image 
> state, but it might be unexpected for some MetadataPublishers. 
>  
> For example, in KRaftMigrationDriver, if an old MetadataVersion is 
> encountered, the driver transitions to the INACTIVE state.



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

Re: Please provide permission to add reviewer in github PR

[Greg Harris]

Hey Arpit,

I'm glad that you're interested in picking up new work!
I think we mainly use the Jira label `newbie` for issues like that.
You may also be able to help with issues marked `flaky-test`, or work
on issues within some component you are more familiar with.

Thanks!
Greg

On Fri, Aug 25, 2023 at 9:28 AM Arpit Goyal  wrote:
>
> Sure I tagged in the jira , will also comment in GitHub.
> Do we maintain a list of issues which beginner can start picking from?
>
> On Fri, Aug 25, 2023, 21:49 Greg Harris 
> wrote:
>
> > Hi Arpit,
> >
> > Contributors aren't typically given permissions to tag reviewers in
> > the kafka repository. Instead, you should @-mention potential
> > reviewers in a github comment.
> >
> > Hope this helps!
> > Greg
> >
> > On Fri, Aug 25, 2023 at 9:15 AM Arpit Goyal 
> > wrote:
> > >
> > > Hi All,
> > > I just generated a patch for one of the tasks. Can someone please help me
> > > provide permission to add reviewer in PR.
> > > PR : https://github.com/apache/kafka/pull/14288
> > > jira : https://issues.apache.org/jira/browse/KAFKA-15256
> > >
> > > Thanks and Regards
> > > Arpit Goyal
> > > 8861094754
> >

Re: What are the biggest issues with Apache Kafka?

[Colin McCabe]

If you want to get more familiar with the code base, one great way is to 
convert more integration tests to KRaft mode.

:)

best,
Colin

On Thu, Aug 10, 2023, at 17:16, Liam Hodges wrote:
> I'm working with a small team of engineers looking to contribute to the
> open source tools for Apache Kafka. What is missing in the Kafka community
> right now? Are there any problems an open source project could solve for
> it's developers? Appreciate all feedback.

Re: [VOTE] KIP-942: Add Power(ppc64le) support

[Colin McCabe]

Thank you for continuing to work on this.

One comment. When we discussed this in the DISCUSS thread, we all wanted to run 
it nightly in branch builder (or possibly weekly). But looking at the KIP, it 
doesn't seem to have been updated with the results of these discussions.

best,
Colin


On Mon, Aug 21, 2023, at 01:37, Mickael Maison wrote:
> +1 (binding)
> Thanks for the KIP!
>
> Mickael
>
> On Mon, Aug 14, 2023 at 1:40 PM Divij Vaidya  wrote:
>>
>> +1 (binding)
>>
>> --
>> Divij Vaidya
>>
>>
>> On Wed, Jul 26, 2023 at 9:04 AM Vaibhav Nazare
>>  wrote:
>> >
>> > I'd like to call a vote on KIP-942

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

[Roger Hoover]

Other than supporting multiplexing transactional streams on a single
producer, I don't see how to improve it.

On Thu, Aug 24, 2023 at 12:12 PM Artem Livshits
 wrote:

> Hi Roger,
>
> Thank you for summarizing the cons.  I agree and I'm curious what would be
> the alternatives to solve these problems better and if they can be
> incorporated into this proposal (or built independently in addition to or
> on top of this proposal).  E.g. one potential extension we discussed
> earlier in the thread could be multiplexing logical transactional "streams"
> with a single producer.
>
> -Artem
>
> On Wed, Aug 23, 2023 at 4:50 PM Roger Hoover 
> wrote:
>
> > Thanks.  I like that you're moving Kafka toward supporting this
> dual-write
> > pattern.  Each use case needs to consider the tradeoffs.  You already
> > summarized the pros very well in the KIP.  I would summarize the cons
> > as follows:
> >
> > - you sacrifice availability - each write requires both DB and Kafka to
> be
> > available so I think your overall application availability is 1 - p(DB is
> > unavailable)*p(Kafka is unavailable).
> > - latency will be higher and throughput lower - each write requires both
> > writes to DB and Kafka while holding an exclusive lock in DB.
> > - you need to create a producer per unit of concurrency in your app which
> > has some overhead in the app and Kafka side (number of connections, poor
> > batching).  I assume the producers would need to be configured for low
> > latency (linger.ms=0)
> > - there's some complexity in managing stable transactional ids for each
> > producer/concurrency unit in your application.  With k8s deployment, you
> > may need to switch to something like a StatefulSet that gives each pod a
> > stable identity across restarts.  On top of that pod identity which you
> can
> > use as a prefix, you then assign unique transactional ids to each
> > concurrency unit (thread/goroutine).
> >
> > On Wed, Aug 23, 2023 at 12:53 PM Artem Livshits
> >  wrote:
> >
> > > Hi Roger,
> > >
> > > Thank you for the feedback.  You make a very good point that we also
> > > discussed internally.  Adding support for multiple concurrent
> > > transactions in one producer could be valuable but it seems to be a
> > fairly
> > > large and independent change that would deserve a separate KIP.  If
> such
> > > support is added we could modify 2PC functionality to incorporate that.
> > >
> > > > Maybe not too bad but a bit of pain to manage these ids inside each
> > > process and across all application processes.
> > >
> > > I'm not sure if supporting multiple transactions in one producer would
> > make
> > > id management simpler: we'd need to store a piece of data per
> > transaction,
> > > so whether it's N producers with a single transaction or N transactions
> > > with a single producer, it's still roughly the same amount of data to
> > > manage.  In fact, managing transactional ids (current proposal) might
> be
> > > easier, because the id is controlled by the application and it knows
> how
> > to
> > > complete the transaction after crash / restart; while a TID would be
> > > generated by Kafka and that would create a question of starting Kafka
> > > transaction, but not saving its TID and then crashing, then figuring
> out
> > > which transactions to abort and etc.
> > >
> > > > 2) creating a separate producer for each concurrency slot in the
> > > application
> > >
> > > This is a very valid concern.  Maybe we'd need to have some
> multiplexing
> > of
> > > transactional logical "streams" over the same connection.  Seems like a
> > > separate KIP, though.
> > >
> > > > Otherwise, it seems you're left with single-threaded model per
> > > application process?
> > >
> > > That's a fair assessment.  Not necessarily exactly single-threaded per
> > > application, but a single producer per thread model (i.e. an
> application
> > > could have a pool of threads + producers to increase concurrency).
> > >
> > > -Artem
> > >
> > > On Tue, Aug 22, 2023 at 7:22 PM Roger Hoover 
> > > wrote:
> > >
> > > > Artem,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > If I understand correctly, Kafka does not support concurrent
> > transactions
> > > > from the same producer (transactional id).  I think this means that
> > > > applications that want to support in-process concurrency (say
> > > thread-level
> > > > concurrency with row-level DB locking) would need to manage separate
> > > > transactional ids and producers per thread and then store txn state
> > > > accordingly.   The potential usability downsides I see are
> > > > 1) managing a set of transactional ids for each application process
> > that
> > > > scales up to it's max concurrency.  Maybe not too bad but a bit of
> pain
> > > to
> > > > manage these ids inside each process and across all application
> > > processes.
> > > > 2) creating a separate producer for each concurrency slot in the
> > > > application - this could create a lot more producers and resultant
> > > 

Re: Please provide permission to add reviewer in github PR

[Arpit Goyal]

Sure I tagged in the jira , will also comment in GitHub.
Do we maintain a list of issues which beginner can start picking from?

On Fri, Aug 25, 2023, 21:49 Greg Harris 
wrote:

> Hi Arpit,
>
> Contributors aren't typically given permissions to tag reviewers in
> the kafka repository. Instead, you should @-mention potential
> reviewers in a github comment.
>
> Hope this helps!
> Greg
>
> On Fri, Aug 25, 2023 at 9:15 AM Arpit Goyal 
> wrote:
> >
> > Hi All,
> > I just generated a patch for one of the tasks. Can someone please help me
> > provide permission to add reviewer in PR.
> > PR : https://github.com/apache/kafka/pull/14288
> > jira : https://issues.apache.org/jira/browse/KAFKA-15256
> >
> > Thanks and Regards
> > Arpit Goyal
> > 8861094754
>

Re: Justine Olshan / thank you (wiki access)

[Justine Olshan]

Hmmm. That's a bit strange if you are subscribed to  dev@kafka.apache.org,
you should be getting responses.

Let me know if this one also doesn't work.

Justine

On Fri, Aug 25, 2023 at 6:04 AM Neil Buesing  wrote:

> Justine,
>
> Thanks for taking care of the wiki access; weird in that response to the
> email never forward to me, I had to see it in the email archive (
> https://lists.apache.org/list.html?dev@kafka.apache.org). I get other
> emails in dev. (I subscribed https://kafka.apache.org/contact)
>
> I am looking to see how to get email responses, or if someone else knows of
> this issue with apache email lists, from the archive page I cannot send
> emails.
>
> Thanks,
>
> Neil
>

Re: Please provide permission to add reviewer in github PR

[Greg Harris]

Hi Arpit,

Contributors aren't typically given permissions to tag reviewers in
the kafka repository. Instead, you should @-mention potential
reviewers in a github comment.

Hope this helps!
Greg

On Fri, Aug 25, 2023 at 9:15 AM Arpit Goyal  wrote:
>
> Hi All,
> I just generated a patch for one of the tasks. Can someone please help me
> provide permission to add reviewer in PR.
> PR : https://github.com/apache/kafka/pull/14288
> jira : https://issues.apache.org/jira/browse/KAFKA-15256
>
> Thanks and Regards
> Arpit Goyal
> 8861094754

Please provide permission to add reviewer in github PR

[Arpit Goyal]

Hi All,
I just generated a patch for one of the tasks. Can someone please help me
provide permission to add reviewer in PR.
PR : https://github.com/apache/kafka/pull/14288
jira : https://issues.apache.org/jira/browse/KAFKA-15256

Thanks and Regards
Arpit Goyal
8861094754

Re: Apache Kafka 3.6.0 release

[Justine Olshan]

Hey Satish,
Everything should be in 3.6, and I will update the release plan wiki.
Thanks!

On Fri, Aug 25, 2023 at 4:08 AM Satish Duggana 
wrote:

> Hi Justine,
> Adding KIP-890 part-1 to 3.6.0 seems reasonable to me. This part looks
> to be addressing a critical issue of consumers getting stuck. Please
> update the release plan wiki and merge all the required changes to 3.6
> branch.
>
> Thanks,
> Satish.
>
> On Thu, 24 Aug 2023 at 22:19, Justine Olshan
>  wrote:
> >
> > Hey Satish,
> > Does it make sense to include KIP-890 part 1? It prevents hanging
> > transactions for older clients. (An optimization and stronger EOS
> > guarantees will be included in part 2)
> >
> > Thanks,
> > Justine
> >
> > On Mon, Aug 21, 2023 at 3:29 AM Satish Duggana  >
> > wrote:
> >
> > > Hi,
> > > 3.6 branch is created. Please make sure any PRs targeted for 3.6.0
> > > should be merged to 3.6 branch once those are merged to trunk.
> > >
> > > Thanks,
> > > Satish.
> > >
> > > On Wed, 16 Aug 2023 at 15:58, Satish Duggana  >
> > > wrote:
> > > >
> > > > Hi,
> > > > Please plan to merge PRs(including the major features) targeted for
> > > > 3.6.0 by the end of Aug 20th UTC. Starting from August 21st, any pull
> > > > requests intended for the 3.6.0 release must include the changes
> > > > merged into the 3.6 branch as mentioned in the release plan.
> > > >
> > > > Thanks,
> > > > Satish.
> > > >
> > > > On Fri, 4 Aug 2023 at 18:39, Chris Egerton 
> > > wrote:
> > > > >
> > > > > Thanks for adding KIP-949, Satish!
> > > > >
> > > > > On Fri, Aug 4, 2023 at 7:06 AM Satish Duggana <
> > > satish.dugg...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > > Myself and Divij discussed and added the wiki for Kafka
> TieredStorage
> > > > > > Early Access Release[1]. If you have any comments or feedback,
> please
> > > > > > feel free to share them.
> > > > > >
> > > > > > 1.
> > > > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes
> > > > > >
> > > > > > Thanks,
> > > > > > Satish.
> > > > > >
> > > > > > On Fri, 4 Aug 2023 at 08:40, Satish Duggana <
> > > satish.dugg...@gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Chris,
> > > > > > > Thanks for the update. This looks to be a minor change and is
> also
> > > > > > > useful for backward compatibility. I added it to the release
> plan
> > > as
> > > > > > > an exceptional case.
> > > > > > >
> > > > > > > ~Satish.
> > > > > > >
> > > > > > > On Thu, 3 Aug 2023 at 21:34, Chris Egerton
>  > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Satish,
> > > > > > > >
> > > > > > > > Would it be possible to include KIP-949 (
> > > > > > > >
> > > > > >
> > >
> https://cwiki.apache.org/confluence/display/KAFKA/KIP-949%3A+Add+flag+to+enable+the+usage+of+topic+separator+in+MM2+DefaultReplicationPolicy
> > > > > > )
> > > > > > > > in the 3.6.0 release? It passed voting yesterday, and is a
> very
> > > small,
> > > > > > > > low-risk change that we'd like to put out as soon as
> possible in
> > > order
> > > > > > to
> > > > > > > > patch an accidental break in backwards compatibility caused
> a few
> > > > > > versions
> > > > > > > > ago.
> > > > > > > >
> > > > > > > > Best,
> > > > > > > >
> > > > > > > > Chris
> > > > > > > >
> > > > > > > > On Fri, Jul 28, 2023 at 2:35 AM Satish Duggana <
> > > > > > satish.dugg...@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi All,
> > > > > > > > > Whoever has KIP entries in the 3.6.0 release plan. Please
> > > update it
> > > > > > > > > with the latest status by tomorrow(end of the day 29th Jul
> UTC
> > > ).
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Satish.
> > > > > > > > >
> > > > > > > > > On Fri, 28 Jul 2023 at 12:01, Satish Duggana <
> > > > > > satish.dugg...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Thanks Ismael and Divij for the suggestions.
> > > > > > > > > >
> > > > > > > > > > One way was to follow the earlier guidelines that we set
> for
> > > any
> > > > > > early
> > > > > > > > > > access release. It looks Ismael already mentioned the
> > > example of
> > > > > > > > > > KRaft.
> > > > > > > > > >
> > > > > > > > > > KIP-405 mentions upgrade/downgrade and limitations
> sections.
> > > We can
> > > > > > > > > > clarify that in the release notes for users on how this
> > > feature
> > > > > > can be
> > > > > > > > > > used for early access.
> > > > > > > > > >
> > > > > > > > > > Divij, We do not want users to enable this feature on
> > > production
> > > > > > > > > > environments in early access release. Let us work
> together
> > > on the
> > > > > > > > > > followups Ismael suggested.
> > > > > > > > > >
> > > > > > > > > > ~Satish.
> > > > > > > > > >
> > > > > > > > > > On Fri, 28 Jul 2023 at 02:24, Divij Vaidya <
> > > > > > divijvaidy...@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > Those are great suggestions, thank you. 

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 305959 lines...]

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldRemoveTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldRemoveTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldUnassignTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldUnassignTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsForUnassignedTasks() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsForUnassignedTasks() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotAssignLockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldNotAssignLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldUnassignLockingTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldUnassignLockingTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeStreamTimePunctuated() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeStreamTimePunctuated() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateEmptyWriteBatches() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateEmptyWriteBatches() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateWriteBatches() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBTimeOrderedKeyValueBytesStoreTest > shouldCreateWriteBatches() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfDbToAddWasAlreadyAddedForOtherSegment() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfDbToAddWasAlreadyAddedForOtherSegment() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldAddItselfToRecordingTriggerWhenFirstValueProvidersAreAddedAfterLastValueProvidersWereRemoved()
 STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldAddItselfToRecordingTriggerWhenFirstValueProvidersAreAddedAfterLastValueProvidersWereRemoved()
 PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldThrowIfValueProvidersToRemoveNotFound() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > shouldThrowIfValueProvidersToRemoveNotFound() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsSameAsOnlyOneOfMultipleCaches() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 86 > 
RocksDBMetricsRecorderTest > 
shouldThrowIfCacheToAddIsSameAsOnlyOneOfMultipleCaches() PASSED

Justine Olshan / thank you (wiki access)

[Neil Buesing]

Justine,

Thanks for taking care of the wiki access; weird in that response to the
email never forward to me, I had to see it in the email archive (
https://lists.apache.org/list.html?dev@kafka.apache.org). I get other
emails in dev. (I subscribed https://kafka.apache.org/contact)

I am looking to see how to get email responses, or if someone else knows of
this issue with apache email lists, from the archive page I cannot send
emails.

Thanks,

Neil

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 306186 lines...]

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldDrainPendingTasksToCreate() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldDrainPendingTasksToCreate() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
onlyRemovePendingTaskToRecycleShouldRemoveTaskFromPendingUpdateActions() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
onlyRemovePendingTaskToRecycleShouldRemoveTaskFromPendingUpdateActions() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseClean() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseClean() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseDirty() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseDirty() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldKeepAddedTasks() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldKeepAddedTasks() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsForUnassignedTasks() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 

Re: Apache Kafka 3.6.0 release

[Satish Duggana]

Hi Justine,
Adding KIP-890 part-1 to 3.6.0 seems reasonable to me. This part looks
to be addressing a critical issue of consumers getting stuck. Please
update the release plan wiki and merge all the required changes to 3.6
branch.

Thanks,
Satish.

On Thu, 24 Aug 2023 at 22:19, Justine Olshan
 wrote:
>
> Hey Satish,
> Does it make sense to include KIP-890 part 1? It prevents hanging
> transactions for older clients. (An optimization and stronger EOS
> guarantees will be included in part 2)
>
> Thanks,
> Justine
>
> On Mon, Aug 21, 2023 at 3:29 AM Satish Duggana 
> wrote:
>
> > Hi,
> > 3.6 branch is created. Please make sure any PRs targeted for 3.6.0
> > should be merged to 3.6 branch once those are merged to trunk.
> >
> > Thanks,
> > Satish.
> >
> > On Wed, 16 Aug 2023 at 15:58, Satish Duggana 
> > wrote:
> > >
> > > Hi,
> > > Please plan to merge PRs(including the major features) targeted for
> > > 3.6.0 by the end of Aug 20th UTC. Starting from August 21st, any pull
> > > requests intended for the 3.6.0 release must include the changes
> > > merged into the 3.6 branch as mentioned in the release plan.
> > >
> > > Thanks,
> > > Satish.
> > >
> > > On Fri, 4 Aug 2023 at 18:39, Chris Egerton 
> > wrote:
> > > >
> > > > Thanks for adding KIP-949, Satish!
> > > >
> > > > On Fri, Aug 4, 2023 at 7:06 AM Satish Duggana <
> > satish.dugg...@gmail.com>
> > > > wrote:
> > > >
> > > > > Hi,
> > > > > Myself and Divij discussed and added the wiki for Kafka TieredStorage
> > > > > Early Access Release[1]. If you have any comments or feedback, please
> > > > > feel free to share them.
> > > > >
> > > > > 1.
> > > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes
> > > > >
> > > > > Thanks,
> > > > > Satish.
> > > > >
> > > > > On Fri, 4 Aug 2023 at 08:40, Satish Duggana <
> > satish.dugg...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > Hi Chris,
> > > > > > Thanks for the update. This looks to be a minor change and is also
> > > > > > useful for backward compatibility. I added it to the release plan
> > as
> > > > > > an exceptional case.
> > > > > >
> > > > > > ~Satish.
> > > > > >
> > > > > > On Thu, 3 Aug 2023 at 21:34, Chris Egerton  > >
> > > > > wrote:
> > > > > > >
> > > > > > > Hi Satish,
> > > > > > >
> > > > > > > Would it be possible to include KIP-949 (
> > > > > > >
> > > > >
> > https://cwiki.apache.org/confluence/display/KAFKA/KIP-949%3A+Add+flag+to+enable+the+usage+of+topic+separator+in+MM2+DefaultReplicationPolicy
> > > > > )
> > > > > > > in the 3.6.0 release? It passed voting yesterday, and is a very
> > small,
> > > > > > > low-risk change that we'd like to put out as soon as possible in
> > order
> > > > > to
> > > > > > > patch an accidental break in backwards compatibility caused a few
> > > > > versions
> > > > > > > ago.
> > > > > > >
> > > > > > > Best,
> > > > > > >
> > > > > > > Chris
> > > > > > >
> > > > > > > On Fri, Jul 28, 2023 at 2:35 AM Satish Duggana <
> > > > > satish.dugg...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi All,
> > > > > > > > Whoever has KIP entries in the 3.6.0 release plan. Please
> > update it
> > > > > > > > with the latest status by tomorrow(end of the day 29th Jul UTC
> > ).
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Satish.
> > > > > > > >
> > > > > > > > On Fri, 28 Jul 2023 at 12:01, Satish Duggana <
> > > > > satish.dugg...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Thanks Ismael and Divij for the suggestions.
> > > > > > > > >
> > > > > > > > > One way was to follow the earlier guidelines that we set for
> > any
> > > > > early
> > > > > > > > > access release. It looks Ismael already mentioned the
> > example of
> > > > > > > > > KRaft.
> > > > > > > > >
> > > > > > > > > KIP-405 mentions upgrade/downgrade and limitations sections.
> > We can
> > > > > > > > > clarify that in the release notes for users on how this
> > feature
> > > > > can be
> > > > > > > > > used for early access.
> > > > > > > > >
> > > > > > > > > Divij, We do not want users to enable this feature on
> > production
> > > > > > > > > environments in early access release. Let us work together
> > on the
> > > > > > > > > followups Ismael suggested.
> > > > > > > > >
> > > > > > > > > ~Satish.
> > > > > > > > >
> > > > > > > > > On Fri, 28 Jul 2023 at 02:24, Divij Vaidya <
> > > > > divijvaidy...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > Those are great suggestions, thank you. We will continue
> > this
> > > > > > > > discussion
> > > > > > > > > > forward in a separate KIP for release plan for Tiered
> > Storage.
> > > > > > > > > >
> > > > > > > > > > On Thu 27. Jul 2023 at 21:46, Ismael Juma <
> > m...@ismaeljuma.com>
> > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi Divij,
> > > > > > > > > > >
> > > > > > > > > > > I think the points you bring up for discussion are all
> > good.
> > > > > My main
> > > > > > > > > > > 

Re: [DISCUSS] KIP-960: Support interactive queries (IQv2) for versioned state stores

[Alieh Saeedi]

Thank you, Matthias and Victoria.

Regarding the problem of using methods of single-key-single-ts queries for
KeyQuery (such as asOf) and vice versa (such as skipCache()), after a
discussion, we decided to define a separate class for single-key-single-ts
queries named VersionedKeyQuery. Subsequently, the
single-key-multi-timestamp queries (KIP-968) and range queries (KIP-969)
will be covered by the MultiVersionedKeyQuery and MultiVersionedRangeQuery
classes, respectively.
I think the VersionedKeyQuery is type-safe since if an instance of the
VersionedKeyQuery is posed to a normal (non-versioned) state store, we will
have the defined Kafka Streams UNKNOWN_QUERY_TYPE failure.

P.S.: The example should be correct now.

Cheers,
Alieh

On Thu, Aug 24, 2023 at 9:34 PM Victoria Xia 
wrote:

>  Hi Alieh,
>
> Thanks for the updates!
> Some questions on the new limited-scope KIP:
> 1. The example in the "Examples" section shows the query type as
> `KeyQuery>` and the result type as
> `StateQueryResult>`. Should those have
> `VersionedRecord` instead of `ValueAndTimestamp`? Also, the request type is
> currently `StateQueryRequest>>`.
> Should the `ValueIterator` no longer be present, now that we are only
> returning a single record?
> 2. Related to Matthias's question about what happens if `asOf()` is set
> for a KeyQuery to a non-versioned store, what happens if `skipCache()` is
> set for a versioned store? And what will `isSkipCache()` return? Versioned
> stores do not support caching (at least today). I think for consistency we
> have to let `isSkipCache()` still default to false if `isSkipCache()` is
> not set. I think that's fine, as long as it's clear to users (e.g., from
> docs) that `isSkipCache()` is not relevant for queries to versioned stores.
> And some responses to your comments from earlier:
> > I changed the VersionedRecord such that it can have NULL values as well.
> The question is, what was the initial intention of setting the value in
> VersionedRecord as NOT NULL?
> We can discuss more on your other KIPs (KIP-968 and KIP-969) since this
> change should only be relevant for those KIPs and not this one, but the
> short answer is that today there's no situation in which VersionedRecord
> would need to return a null value because if a get(key) or get(key,
> asOfTimestamp) call to a versioned store were to find a null record (i.e.,
> tombstone), then a null object is returned, rather than a non-null
> VersionedRecord with null value. In other words, versioned stores do not
> distinguish between a tombstone having been inserted versus no record ever
> having been inserted.
> > About defining new methods in the VersionedKeyValueStore interface: I
> actually have defined the required methods in the RocksDBVersionedStore
> class. Since defining them for the interface requires implementing them for
> all the classes that have implemented the interface.
> Again a discussion for your other KIPs, but I think you'll want to define
> the new method(s) in the VersionedKeyValueStore interface directly (rather
> than only in individual implementations such as RocksDBVersionedStore),
> otherwise your new interactive query types will throw NPEs for custom store
> implementations which do not support the new methods.
> Best,VictoriaOn Thursday, August 17, 2023 at 07:25:22 AM EDT, Alieh
> Saeedi  wrote:
>
>  Hey Matthias,
> thanks for the feedback
>
> I think if one materializes a versioned store, then the query is posed to
> the versioned state store. So the type of materialized store determines the
> type of store and consequently all the classes for running the query (for
> example, MeteredVersionedKeyValueStore instead of MeteredKeyValueStore and
> so on). I added the piece of code for defining the versioned state store to
> the example part of the KIP-960.
>
> About the generics, using VersionedRecord instead of V worked. Right
> now, I am composing the integration tests. Let me complete the code and
> confirm it for 100%.
>
> About the KeyQuery class, I thought the KIP must contain just the newly
> added stuff. OK, I will paste the whole class in KIP-960.
>
> Thanks,
> Alieh
>
>
>
>
> On Thu, Aug 17, 2023 at 3:54 AM Matthias J. Sax  wrote:
>
> > Thanks for updating the KIP and splitting into multiple ones. I am just
> > going to reply for the single-key-single-timestamp case below.
> >
> > It seems the `KeyQuery.java` code snipped is "incomplete" -- the class
> > definition is missing.
> >
> > At the same time, the example uses `VersionedKeyQuery` so I am not sure
> > right now if you propose to re-use the existing `KeyQuery` class or
> > introduce a new `VersionedKeyQuery` class?
> >
> > While it was suggested that we re-use the existing `KeyQuery` class, I
> > am wondering what would happen if one uses the new `asOf` method, and
> > passes the query into a non-versioned store?
> >
> > In the end, a non-versioned store does not know that there is an as-of
> > timestamp set and thus might just do a plain 

[jira] [Created] (KAFKA-15405) Create a new error code to indicate a resource is not ready yet

[Abhijeet Kumar (Jira)]

Abhijeet Kumar created KAFKA-15405:
--

 Summary: Create a new error code to indicate a resource is not 
ready yet
 Key: KAFKA-15405
 URL: https://issues.apache.org/jira/browse/KAFKA-15405
 Project: Kafka
  Issue Type: Task
Reporter: Abhijeet Kumar


We need a new error code to indicate to the client that the resource is not 
ready on the server yet and is initializing. When the client receives this 
error it should retry again.



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

Re: [REVIEW REQUEST] Move ReassignPartitionsCommandArgsTest to java

[Mickael Maison]

Hi Nikolay,

Thanks for working on this feature. Take into account that many people
are on PTO at the moment and there's a lot of PRs to review.
Not sure why fixVersion was set to 3.6.0. Apart for key features or
fixes, it's usually best to only set the fixVersion once the code has
been merged. I've cleared that field.

Thanks,
Mickael

On Fri, Aug 25, 2023 at 9:26 AM Николай Ижиков  wrote:
>
> Hello, Luke
>
> Thanks for reply.
>
> Actually, KAFKA-14595 [1] has fixVersion = 3.6.0
> And the PR is part of the ticket.
>
> Several review required If we want to include java version of 
> ReassignPartitionCommand in 3.6.0
>
> [1] https://issues.apache.org/jira/browse/KAFKA-14595
>
>
> > 23 авг. 2023 г., в 10:07, Luke Chen  написал(а):
> >
> > Hi,
> >
> > Sorry that we're mostly working on features for v3.6.0, which is expected
> > to be released in the following weeks.
> > I'll review your PR after releasing. (Please ping me then if I forget it!)
> >
> > Also, it'd be good if the devs in the community can help on PR review when
> > available.
> > That'll help a lot.
> > Besides, PR review is also one kind of contribution, not just code
> > commitment.
> >
> > Thanks.
> > Luke
> >
> >
> >
> > On Tue, Aug 22, 2023 at 7:15 PM Николай Ижиков  wrote:
> >
> >> Hello.
> >>
> >> Please, join the simple review)
> >> We have few steps left to completely rewrite ReassignPartitionsCommand in
> >> java.
> >>
> >>> 17 авг. 2023 г., в 17:16, Николай Ижиков 
> >> написал(а):
> >>>
> >>> Hello.
> >>>
> >>> I’m working on [1].
> >>> The goal of ticket is to rewire `ReassignPartitionCommand` in java.
> >>>
> >>> The PR that moves whole command is pretty big so it makes sense to split
> >> it.
> >>> I prepared the PR [2] that moves single test
> >> (ReassignPartitionsCommandArgsTest) to java.
> >>>
> >>> It relatively small and simple(touches only 3 files):
> >>>
> >>> To review - https://github.com/apache/kafka/pull/14217
> >>> Big PR  - https://github.com/apache/kafka/pull/13247
> >>>
> >>> Please, review.
> >>>
> >>> [1] https://issues.apache.org/jira/browse/KAFKA-14595
> >>> [2] https://github.com/apache/kafka/pull/14217
> >>
> >>
>

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

[Apache Jenkins Server]

See 


Changes:


--
[...truncated 305992 lines...]

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
onlyRemovePendingTaskToCloseCleanShouldRemoveTaskFromPendingUpdateActions() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldDrainPendingTasksToCreate() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldDrainPendingTasksToCreate() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
onlyRemovePendingTaskToRecycleShouldRemoveTaskFromPendingUpdateActions() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
onlyRemovePendingTaskToRecycleShouldRemoveTaskFromPendingUpdateActions() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseClean() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseClean() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseDirty() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldAddAndRemovePendingTaskToCloseDirty() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldKeepAddedTasks() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > TasksTest > 
shouldKeepAddedTasks() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTasksThatCanBeSystemTimePunctuated() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotUnassignNotOwnedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotSetUncaughtExceptionsTwice() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForPunctuationIfPunctuationDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAddTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotAssignAnyLockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldRemoveTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveAssignedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldAssignTaskThatCanBeProcessed() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldNotRemoveUnlockedTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldReturnAndClearExceptionsOnDrainExceptions() 
PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > shouldUnassignTask() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() STARTED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 
shouldNotAssignTasksForProcessingIfProcessingDisabled() PASSED

Gradle Test Run :streams:test > Gradle Test Executor 84 > 
DefaultTaskManagerTest > 

Re: [REVIEW REQUEST] Move ReassignPartitionsCommandArgsTest to java

[Николай Ижиков]

Hello, Luke

Thanks for reply.

Actually, KAFKA-14595 [1] has fixVersion = 3.6.0
And the PR is part of the ticket.

Several review required If we want to include java version of 
ReassignPartitionCommand in 3.6.0

[1] https://issues.apache.org/jira/browse/KAFKA-14595


> 23 авг. 2023 г., в 10:07, Luke Chen  написал(а):
> 
> Hi,
> 
> Sorry that we're mostly working on features for v3.6.0, which is expected
> to be released in the following weeks.
> I'll review your PR after releasing. (Please ping me then if I forget it!)
> 
> Also, it'd be good if the devs in the community can help on PR review when
> available.
> That'll help a lot.
> Besides, PR review is also one kind of contribution, not just code
> commitment.
> 
> Thanks.
> Luke
> 
> 
> 
> On Tue, Aug 22, 2023 at 7:15 PM Николай Ижиков  wrote:
> 
>> Hello.
>> 
>> Please, join the simple review)
>> We have few steps left to completely rewrite ReassignPartitionsCommand in
>> java.
>> 
>>> 17 авг. 2023 г., в 17:16, Николай Ижиков 
>> написал(а):
>>> 
>>> Hello.
>>> 
>>> I’m working on [1].
>>> The goal of ticket is to rewire `ReassignPartitionCommand` in java.
>>> 
>>> The PR that moves whole command is pretty big so it makes sense to split
>> it.
>>> I prepared the PR [2] that moves single test
>> (ReassignPartitionsCommandArgsTest) to java.
>>> 
>>> It relatively small and simple(touches only 3 files):
>>> 
>>> To review - https://github.com/apache/kafka/pull/14217
>>> Big PR  - https://github.com/apache/kafka/pull/13247
>>> 
>>> Please, review.
>>> 
>>> [1] https://issues.apache.org/jira/browse/KAFKA-14595
>>> [2] https://github.com/apache/kafka/pull/14217
>> 
>> 

Jenkins build is still unstable: Kafka » Kafka Branch Builder » 3.6 #6

[Apache Jenkins Server]

See