jolshan commented on code in PR #13901:
URL: https://github.com/apache/kafka/pull/13901#discussion_r1244506236
##########
group-coordinator/src/main/java/org/apache/kafka/coordinator/group/consumer/ConsumerGroup.java:
##########
@@ -119,6 +131,18 @@ public String toString() {
*/
private final TimelineHashMap<Uuid, TimelineHashMap<Integer, Integer>>
currentPartitionEpoch;
+ /**
+ * The next metadata refresh time. It consists of a timestamp in
milliseconds together with
+ * the group epoch at the time of setting it. The metadata refresh time is
considered as a
+ * soft state (read that it is not stored in a timeline data structure).
It is like this
+ * because it is not persisted to the log. The group epoch is here to
ensure that the
+ * next metadata refresh time is invalidated if the group epoch does not
correspond to
+ * the current group epoch. This can happen if the next metadata refresh
time is updated
+ * after having refreshed the metadata but the write operation failed. In
this case, the
+ * time is not automatically rollback.
Review Comment:
nit: automatically rolled back.
Also in this case, do we not update the refresh time until the epoch bump
and write succeed? And we will keep refreshing the metadata in the meantime?
--
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
