Hi, happy to see such a great proposal. Increment Checkpointing is really
necessary for jobs with states in large scale, which can save both space
and time spent on checkpointing.
For checkpoints, I think that it is better to leave the state backend to
decide whether a checkpoint is incremental or
jing lining created FLINK-5844:
--
Summary: jobmanager was killed when disk less 10% and restart fail
Key: FLINK-5844
URL: https://issues.apache.org/jira/browse/FLINK-5844
Project: Flink
Issue Typ
Hi Gyula,
It's the backend that decides the data contained in the snapshot. The backend
can take a complete snapshot when it finds it cost more to take an incremental
snapshot. In such cases, the taken snapshots are self-contained and will not
reference any previous deltas.
It's true that the gr
Patrick Lucas created FLINK-5843:
Summary: Website/docs missing Cache-Control HTTP header, can serve
stale data
Key: FLINK-5843
URL: https://issues.apache.org/jira/browse/FLINK-5843
Project: Flink
Dawid Wysakowicz created FLINK-5842:
---
Summary: Wrong 'since' version for ElasticSearch 5.x connector
Key: FLINK-5842
URL: https://issues.apache.org/jira/browse/FLINK-5842
Project: Flink
Iss
Hi,
I would like to start a discussion about next steps for Flink ML.
Currently there is a lot of work going on but needs a push forward.
Some topics to discuss:
a) How several features should be planned and get aligned with Flink
releases.
b) Priorities of what should be done.
c) Basic guidelin
