carp84 commented on a change in pull request #7674: [FLINK-10043] [State
Backends] Refactor RocksDBKeyedStateBackend object
construction/initialization/restore code
URL: https://github.com/apache/flink/pull/7674#discussion_r257755359
##########
File path:
flink-streaming-java/src/main/java/org/apache/flink/streaming/api/operators/BackendRestorerProcedure.java
##########
@@ -141,14 +141,17 @@ public T createAndRestore(@Nonnull List<? extends
Collection<S>> restoreOptions)
private T attemptCreateAndRestore(Collection<S> restoreState) throws
Exception {
// create a new, empty backend.
- final T backendInstance = instanceSupplier.get();
+ final T backendInstance = instanceSupplier.apply(restoreState);
try {
// register the backend with the registry to
participate in task lifecycle w.r.t. cancellation.
backendCloseableRegistry.registerCloseable(backendInstance);
// attempt to restore from snapshot (or null if no
state was checkpointed).
- backendInstance.restore(restoreState);
+ // TODO we could remove this invocation when moving all
backend's restore into builder
+ if
(!backendInstance.getClass().getName().contains("RocksDBKeyedStateBackend")) {
Review comment:
Yes you are correct, I've already checked and confirmed the merge of create
and restore could work well for rocksdb. Back to the review here, is it ok to
keep this `contains` logic for the time being and fix it later in the
to-be-created JIRA for other backend's refactoring? Thanks.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
