dajac commented on a change in pull request #11665:
URL: https://github.com/apache/kafka/pull/11665#discussion_r788499923
##########
File path: core/src/test/scala/unit/kafka/server/ReplicaManagerTest.scala
##########
@@ -3541,7 +3541,14 @@ class ReplicaManagerTest {
val version = if (usesTopicIds)
LeaderAndIsrRequestData.HIGHEST_SUPPORTED_VERSION else 4.toShort
val topicId = if (usesTopicIds) this.topicId else Uuid.ZERO_UUID
val topicIdOpt = if (usesTopicIds) Some(topicId) else None
- val replicaManager = setupReplicaManagerWithMockedPurgatories(new
MockTimer(time))
+
+ // We use a low `replica.fetch.max.bytes` in order to have multiple fetch
+ // requests issued by the ReplicaAlterLogDirsThread.
+ val replicaManager = setupReplicaManagerWithMockedPurgatories(
+ new MockTimer(time),
+ propsModifier = props => props.put(KafkaConfig.ReplicaFetchMaxBytesProp,
"1")
Review comment:
The issue is quite subtile. The intent here is to ensures that the
fetcher uses multiple fetch requests to replicate the data to the new log. The
issue is that both `assertFetcherHasTopicId` and `processFetchRequest` compete
for the `partitionMapLock` lock. If `assertFetcherHasTopicId` gets it first,
the test pass. If `processFetchRequest` gets it first, the test fail because
the fetch state is removed while holding the lock. By using multiple fetch
requests, `assertFetcherHasTopicId` has a chance to verify the state before the
copy is completed.
--
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
