jolshan commented on code in PR #13112:
URL: https://github.com/apache/kafka/pull/13112#discussion_r1080665363
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupCoordinator.java:
##########
@@ -215,4 +223,86 @@ CompletableFuture<OffsetDeleteResponseData> deleteOffsets(
OffsetDeleteRequestData request,
BufferSupplier bufferSupplier
);
+
+ /**
+ * Return the partition index for the given Group.
+ *
+ * @param groupId The group id.
+ *
+ * @return The partition index.
+ */
+ int partitionFor(String groupId);
+
+ /**
+ * Commit or abort the pending transactional offsets for the given
partitions.
+ *
+ * @param producerId The producer id.
+ * @param partitions The partitions.
+ * @param transactionResult The result of the transaction.
+ */
+ void onTransactionCompleted(
+ long producerId,
+ Iterable<TopicPartition> partitions,
+ TransactionResult transactionResult
+ );
+
+ /**
+ * Delete the provided partitions' offsets.
+ *
+ * @param topicPartitions The deleted partitions.
+ * @param bufferSupplier The buffer supplier tight to the request
thread.
+ */
+ void onPartitionsDeleted(
+ List<TopicPartition> topicPartitions,
+ BufferSupplier bufferSupplier
+ );
+
+ /**
+ * Group coordinator is now the leader for the given partition at the
+ * given leader epoch. It should load cached state from the partition
+ * and begin handling requests for groups mapped to it.
+ *
+ * @param partitionIndex The partition index.
+ * @param partitionLeaderEpoch The leader epoch of the partition.
Review Comment:
Few questions -- this is the coordinator's state topic partitions -- ie
__consumer_offsets or a different partition?
I also noticed in the current group coordinator implementation, we call the
second parameter "coordinatorEpoch" is the equivalent to the leader epoch for
the the partition its managing?
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/GroupCoordinator.java:
##########
@@ -215,4 +223,86 @@ CompletableFuture<OffsetDeleteResponseData> deleteOffsets(
OffsetDeleteRequestData request,
BufferSupplier bufferSupplier
);
+
+ /**
+ * Return the partition index for the given Group.
+ *
+ * @param groupId The group id.
+ *
+ * @return The partition index.
+ */
+ int partitionFor(String groupId);
+
+ /**
+ * Commit or abort the pending transactional offsets for the given
partitions.
+ *
+ * @param producerId The producer id.
+ * @param partitions The partitions.
+ * @param transactionResult The result of the transaction.
+ */
+ void onTransactionCompleted(
+ long producerId,
+ Iterable<TopicPartition> partitions,
+ TransactionResult transactionResult
+ );
+
+ /**
+ * Delete the provided partitions' offsets.
+ *
+ * @param topicPartitions The deleted partitions.
+ * @param bufferSupplier The buffer supplier tight to the request
thread.
+ */
+ void onPartitionsDeleted(
+ List<TopicPartition> topicPartitions,
+ BufferSupplier bufferSupplier
+ );
+
+ /**
+ * Group coordinator is now the leader for the given partition at the
+ * given leader epoch. It should load cached state from the partition
+ * and begin handling requests for groups mapped to it.
+ *
+ * @param partitionIndex The partition index.
+ * @param partitionLeaderEpoch The leader epoch of the partition.
Review Comment:
Few questions -- this is the coordinator's state topic partitions -- ie
__consumer_offsets or a different partition?
I also noticed in the current group coordinator implementation, we call the
second parameter "coordinatorEpoch" is the equivalent to the leader epoch for
the the partition it's managing?
--
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
