Zakelly commented on code in PR #26202:
URL: https://github.com/apache/flink/pull/26202#discussion_r1979288504
##########
flink-state-backends/flink-statebackend-forst/src/main/java/org/apache/flink/state/forst/ForStKeyedStateBackendBuilder.java:
##########
@@ -259,10 +259,14 @@ public ForStKeyedStateBackend<K> build() throws
BackendBuildingException {
defaultColumnFamilyHandle =
restoreResult.getDefaultColumnFamilyHandle();
nativeMetricMonitor = restoreResult.getNativeMetricMonitor();
- // TODO: init materializedSstFiles and lastCompletedCheckpointId
when implement restore
SortedMap<Long,
Collection<IncrementalKeyedStateHandle.HandleAndLocalPath>>
materializedSstFiles = new TreeMap<>();
long lastCompletedCheckpointId = -1L;
+ if (restoreOperation instanceof ForStIncrementalRestoreOperation) {
+ backendUID = restoreResult.getBackendUID();
+ materializedSstFiles = restoreResult.getRestoredSstFiles();
+ lastCompletedCheckpointId =
restoreResult.getLastCompletedCheckpointId();
+ }
Review Comment:
> About the inheritance in `NO_CLAIM` mode: I noticed that RocksDB does not
handle the `NO_CLAIM` case specially during restoration. So, I think the story
here is: when building the state backend, we simply record the materialized SST
files as our previous snapshot. Later, during the first checkpoint, since the
sharing strategy is `FORWARD`, we will clear the previous snapshot. This also
ensures the correctness of the `NO_CLAIM` semantics.
The files are cleared by JM right? Not from TM side. So we don't need the
inheritance in the first place.
--
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: issues-unsubscr...@flink.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
