curcur commented on a change in pull request #14943:
URL: https://github.com/apache/flink/pull/14943#discussion_r583686130
##########
File path:
flink-runtime/src/main/java/org/apache/flink/runtime/state/StateBackendLoader.java
##########
@@ -204,6 +222,11 @@ public static StateBackend
fromApplicationOrConfigOrDefault(
// (1) the application defined state backend has precedence
if (fromApplication != null) {
+
+ checkArgument(
+ !(fromApplication instanceof DelegateStateBackend),
+ "DelegateStateBackend can not be delegated!");
Review comment:
When I said why not, I was thinking of why does `deserialization` matter
here? Or put it another way, `deserialization` in where for what? And why does
`deserialization` be a concern?
If you mean the read config deserialization in JM or TM, it does not matter
because we do not allow `changelogstatebackend` from the application. Even if
we do, that should not be a problem as well, because DelegateStateBackend is a
StateBackend which is `java.io.Serializable`. At least from all ITTests, I ran
so far, I did not see that type of problems.
Or do you mean something else?
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
