showuon commented on code in PR #15263:
URL: https://github.com/apache/kafka/pull/15263#discussion_r1471075201
##########
core/src/main/scala/kafka/server/ReplicaManager.scala:
##########
@@ -2759,11 +2761,20 @@ class ReplicaManager(val config: KafkaConfig,
delta: TopicsDelta,
topicId: Uuid): Option[(Partition,
Boolean)] = {
getPartition(tp) match {
- case HostedPartition.Offline =>
- stateChangeLogger.warn(s"Unable to bring up new local leader $tp " +
- s"with topic id $topicId because it resides in an offline log " +
- "directory.")
- None
+ case HostedPartition.Offline(offlinePartition) =>
+ if (offlinePartition.flatMap(p => p.topicId).contains(topicId)) {
+ stateChangeLogger.warn(s"Unable to bring up new local leader $tp " +
+ s"with topic id $topicId because it resides in an offline log " +
+ "directory.")
+ None
+ } else {
+ stateChangeLogger.info(s"Creating new partition $tp with topic id "
+ s"$topicId." +
+ s"A topic with the same name but different id exists but it
resides in an offline log " +
+ s"directory.")
Review Comment:
What would be the impact if we don't fix it?
Since currently, we're assuming the topicPartition with another topic ID is
located on a dir with No state. So I'm thinking the impact would be that:
1. if the partition is on another dir which already has the Online state, we
will create a duplicated one, or the state will be wrong.
2. if the partition is on another dir which is offline, we'll try to create
it, but got exception without good handler (I think).
3. Anything else?
Given this case is pretty rare that only happen when the topic name is the
same, I agree we can create another JIRA for that improvement.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
