hachikuji commented on code in PR #14702:
URL: https://github.com/apache/kafka/pull/14702#discussion_r1409800961
##########
core/src/test/scala/integration/kafka/api/TransactionsTest.scala:
##########
@@ -820,6 +823,37 @@ class TransactionsTest extends IntegrationTestHarness {
assertEquals((initialProducerEpoch + 1).toShort,
producerStateEntry.producerEpoch)
}
+ @ParameterizedTest(name = TestInfoUtils.TestWithParameterizedQuorumName)
+ @ValueSource(strings = Array("zk", "kraft"))
+ def testTransactionsWithCompression(quorum: String): Unit = {
+ val numRecords = 50
+ val numProducersWithCompression = 5
+ val numTransactions = 40
+ val transactionalCompressionProducers = Buffer[KafkaProducer[Array[Byte],
Array[Byte]]]()
+
+ for (i <- 0 until numProducersWithCompression) {
+ transactionalCompressionProducers +=
createTransactionalProducer("transactional-compression-producer-" + i.toString,
compressionType = "snappy")
+ }
+
+ // KAFKA-15653 is triggered more easily with replication factor 1
Review Comment:
Not sure I follow that. Whether there are any replicas or not, wouldn't the
request thread will be freed after sending out the verification? One way I
could see the case being more likely is if we added additional request threads.
I don't think there's any affinity in the callback to the original request
thread, is there? So more available request threads probably means a greater
chance a separate thread would handle the callback. Does that make sense?
--
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: jira-unsubscr...@kafka.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
