[
https://issues.apache.org/jira/browse/KAFKA-21252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chia-Ping Tsai updated KAFKA-21252:
-----------------------------------
Description:
{code:java}
val proposedAssignmentForNewPartitions = replicaAssignment.getOrElse {
val startIndex = math.max(0, allBrokers.indexWhere(_.id >=
existingAssignmentPartition0.head))
CoreUtils.replicaToBrokerAssignmentAsScala(AdminUtils.assignReplicasToBrokers(allBrokers.asJava,
partitionsToAdd, existingAssignmentPartition0.size,
startIndex, existingAssignment.size))
} {code}
The zk broker picks partition 0’s replicas for the newly created partitions.
{code:java}
Iterator<PartitionRegistration> iterator =
topicInfo.parts.values().iterator();
if (!iterator.hasNext()) {
throw new UnknownServerException("Invalid state: topic " +
topic.name() +
" appears to have no partitions.");
}
PartitionRegistration partitionInfo = iterator.next();
if (partitionInfo.replicas.length > Short.MAX_VALUE) {
throw new UnknownServerException("Invalid replication factor " +
partitionInfo.replicas.length + ": expected a number equal to
less than " +
Short.MAX_VALUE);
}
short replicationFactor = (short) partitionInfo.replicas.length;{code}
By contrast, the kraft broker picks the "first" partition, but the "first"
depends on the hash slot layout. Hence, it is unpredictable to users :(
It can be fixed simply by replacing the `.next` to `parts.get(0)` :)
was:
{code:java}
val proposedAssignmentForNewPartitions = replicaAssignment.getOrElse {
val startIndex = math.max(0, allBrokers.indexWhere(_.id >=
existingAssignmentPartition0.head))
CoreUtils.replicaToBrokerAssignmentAsScala(AdminUtils.assignReplicasToBrokers(allBrokers.asJava,
partitionsToAdd, existingAssignmentPartition0.size,
startIndex, existingAssignment.size))
} {code}
The zk broker picks partition 0’s replicas for the newly created partitions.
{code:java}
Iterator<PartitionRegistration> iterator =
topicInfo.parts.values().iterator();
if (!iterator.hasNext()) {
throw new UnknownServerException("Invalid state: topic " +
topic.name() +
" appears to have no partitions.");
} {code}
By contrast, the kraft broker picks the "first" partition, but the "first"
depends on the hash slot layout. Hence, it is unpredictable to users :(
It can be fixed simply by replacing the `.next` to `parts.get(0)` :)
> NewPartitions#increaseTo no longer follows partition 0’s replication factor
> in KRaft mode
> -----------------------------------------------------------------------------------------
>
> Key: KAFKA-21252
> URL: https://issues.apache.org/jira/browse/KAFKA-21252
> Project: Kafka
> Issue Type: Improvement
> Reporter: Chia-Ping Tsai
> Assignee: Chia-Ping Tsai
> Priority: Minor
>
> {code:java}
> val proposedAssignmentForNewPartitions = replicaAssignment.getOrElse {
> val startIndex = math.max(0, allBrokers.indexWhere(_.id >=
> existingAssignmentPartition0.head))
>
> CoreUtils.replicaToBrokerAssignmentAsScala(AdminUtils.assignReplicasToBrokers(allBrokers.asJava,
> partitionsToAdd, existingAssignmentPartition0.size,
> startIndex, existingAssignment.size))
> } {code}
> The zk broker picks partition 0’s replicas for the newly created partitions.
> {code:java}
> Iterator<PartitionRegistration> iterator =
> topicInfo.parts.values().iterator();
> if (!iterator.hasNext()) {
> throw new UnknownServerException("Invalid state: topic " +
> topic.name() +
> " appears to have no partitions.");
> }
> PartitionRegistration partitionInfo = iterator.next();
> if (partitionInfo.replicas.length > Short.MAX_VALUE) {
> throw new UnknownServerException("Invalid replication factor " +
> partitionInfo.replicas.length + ": expected a number equal to
> less than " +
> Short.MAX_VALUE);
> }
> short replicationFactor = (short) partitionInfo.replicas.length;{code}
> By contrast, the kraft broker picks the "first" partition, but the "first"
> depends on the hash slot layout. Hence, it is unpredictable to users :(
> It can be fixed simply by replacing the `.next` to `parts.get(0)` :)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
