[ https://issues.apache.org/jira/browse/FLINK-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940602#comment-15940602 ]
ASF GitHub Bot commented on FLINK-5715: --------------------------------------- Github user StefanRRichter commented on a diff in the pull request: https://github.com/apache/flink/pull/3602#discussion_r107935639 --- Diff: flink-tests/src/test/java/org/apache/flink/test/checkpointing/AbstractEventTimeWindowCheckpointingITCase.java --- @@ -115,6 +117,14 @@ public static void stopTestCluster() { @Before public void initStateBackend() throws IOException { switch (stateBackendEnum) { + case MEM_ASYNC: + this.stateBackend = new AsyncMemoryStateBackend(MAX_MEM_STATE_SIZE); + break; + case FILE_ASYNC: { + String backups = tempFolder.newFolder().getAbsolutePath(); + this.stateBackend = new AsyncFsStateBackend("file://" + backups); --- End diff -- That is true. This similar issue should have been there, because this is basically just copy-paste from the `case FILE`. I will fix both. > 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 > Fix For: 1.3.0 > > > 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)