dajac commented on code in PR #13901:
URL: https://github.com/apache/kafka/pull/13901#discussion_r1245212300
##########
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:
It is actually the other way around. The refresh time is updated immediately
but it is not rolled back if the write failed. This is the reason why I have
included the group epoch.
--
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
