Details
-
Improvement
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
Description
Some state backend and checkpoint related options don't set the default value directly, but but they implement default value based on code. Such as:
- execution.checkpointing.tolerable-failed-checkpoints
- state.backend.type
Option1
execution.checkpointing.tolerable-failed-checkpoints doesn't have default value, but CheckpointConfig#getTolerableCheckpointFailureNumber callsĀ configuration.getOptional(ExecutionCheckpointingOptions.TOLERABLE_FAILURE_NUMBER).orElse(0).
It means the 0 is default value of execution.checkpointing.tolerable-failed-checkpoints.
Option2
state.backend.type does't have default value, but StateBackendLoader#loadFromApplicationOrConfigOrDefaultInternal callsĀ
loadStateBackendFromConfig(config, classLoader, logger). When the return value is null, Flink will consider the hashmap as the default state backend.
I checked all callers of StateBackendLoader#loadStateBackendFromConfig, if we change the default value of state.backend.type to hashmap. All of them work well.
Why set the default value directly is fine?
From user side, it's clearer.
From flink developers or maintainers side, it's easy to maintain.
Proposed changes:
Adding the default value for them:
- execution.checkpointing.tolerable-failed-checkpoints: 0
- state.backend.type: hashmap
Note: this JIAR adds the default value, but the behaviour is absolutely same with old one, so it doesn't introduce any effect for users. (So the FLIP isn't necessary IIUC.)
Attachments
Issue Links
- links to