[
https://issues.apache.org/jira/browse/FLINK-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15927806#comment-15927806
]
ASF GitHub Bot commented on FLINK-5715:
---------------------------------------
Github user StefanRRichter commented on a diff in the pull request:
https://github.com/apache/flink/pull/3466#discussion_r106385143
--- Diff:
flink-runtime/src/main/java/org/apache/flink/runtime/state/filesystem/FsStateBackend.java
---
@@ -97,6 +100,27 @@ public FsStateBackend(String checkpointDataUri) throws
IOException {
*
* @param checkpointDataUri The URI describing the filesystem (scheme
and optionally authority),
* and the path to the checkpoint data
directory.
+ * @param asynchronousSnapshots Switch to enable asynchronous snapshots.
+ *
+ * @throws IOException Thrown, if no file system can be found for the
scheme in the URI.
+ */
+ public FsStateBackend(String checkpointDataUri, boolean
asynchronousSnapshots) throws IOException {
--- End diff --
For now, I suggest to keep it as is and as soon as your PR goes in, we have
a followup, that introduced a single entry point to a builder for all backend
related configuration options that helps the user to see and navigate all
options in a more centralized way, e.g.
`KeyedBackends.heap().async(true).create()`.
> Asynchronous snapshotting for HeapKeyedStateBackend
> ---------------------------------------------------
>
> Key: FLINK-5715
> URL: https://issues.apache.org/jira/browse/FLINK-5715
> Project: Flink
> Issue Type: New Feature
> Components: State Backends, Checkpointing
> Affects Versions: 1.3.0
> Reporter: Stefan Richter
> Assignee: Stefan Richter
>
> Blocking snapshots render the HeapKeyedStateBackend practically unusable for
> many user in productions. Their jobs can not tolerate stopped processing for
> the time it takes to write gigabytes of data from memory to disk.
> Asynchronous snapshots would be a solution to this problem. The challenge for
> the implementation is coming up with a copy-on-write scheme for the in-memory
> hash maps that build the foundation of this backend. After taking a closer
> look, this problem is twofold. First, providing CoW semantics for the hashmap
> itself, as a mutible structure, thereby avoiding costly locking or blocking
> where possible. Second, CoW for the mutable value objects, e.g. through
> cloning via serializers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
