junrao commented on code in PR #14629:
URL: https://github.com/apache/kafka/pull/14629#discussion_r1382035051
##########
core/src/main/scala/kafka/server/ReplicaManager.scala:
##########
@@ -864,6 +778,111 @@ class ReplicaManager(val config: KafkaConfig,
}
}
+ /*
+ * Note: This method can be used as a callback in a different request
thread. Ensure that correct RequestLocal
+ * is passed when executing this method. Accessing non-thread-safe data
structures should be avoided if possible.
+ */
+ private def appendEntries(allEntries: Map[TopicPartition, MemoryRecords],
+ internalTopicsAllowed: Boolean,
+ origin: AppendOrigin,
+ requiredAcks: Short,
+ verificationGuards: Map[TopicPartition,
VerificationGuard],
Review Comment:
> The ordering of the requests themselves is not guaranteed already.
It's true that there is not strong ordering guarantee among different
clients. However, the ordering how the group coordinator serializes them in the
log seems important.
Consider an example. A group coordinator receives a joinGroup request from
client 1 first and generates a group record rec1=GroupA(members: client1). It
then receives joinGroup request from client 2 and generates a group record
rec2=GroupA(members: client1, client2). If rec1 comes after rec2 in the log and
the coordinator fails over, the new coordinator will restore the group state to
include only client1 as its members and lose the valid member client2.
Consider another example that involves consumer offsets. A group coordinator
starts with a state in which client 1 owns partition 1. It receives an offset
commit request from client 1 on partition 1. This is a valid request since
client 1 owns partition 1. So, it generates rec3=
GroupA(offsetForPartition1=100). A rebalance happens. The coordinator
re-assigns partition 1 to client 2 and generates rec4= GroupA(partition1 owned
by client 2). If rec3 comes after rec4 in the log and the coordinator fails
over, when the new coordinator rebuilds its state, rec3 will look like invalid
since it happens when client1 no longer owns partition 1.
--
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]
