[
https://issues.apache.org/jira/browse/FLINK-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15938289#comment-15938289
]
ASF GitHub Bot commented on FLINK-5715:
---------------------------------------
GitHub user StefanRRichter opened a pull request:
https://github.com/apache/flink/pull/3602
[FLINK-5715] Asynchronous snapshots for heap keyed state backend (BACKPORT)
Backport of PR #3466 from 1.3-snapshot to 1.2. Introduces asynchronous
snapshots for heap keyed state backend.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/StefanRRichter/flink async-backport
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/flink/pull/3602.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #3602
----
commit c40a8d18a5b1c9f3ccd84701bbe1bd7d4a00924c
Author: Stefan Richter <[email protected]>
Date: 2017-03-23T10:36:56Z
[FLINK-5715] Asynchronous snapshots for heap-based keyed state backend
(backport from 1.3)
----
> 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)
