Hi Andrew,
the reason why the program doesn't fail (and cannot fail, with the current
architecture) is that the partitioned state is dynamic/lazy. For example,
the count trigger might have a partitioned state called "count" that it
uses to keep track of the count. The time trigger requires no state
Thanks Ufuk.
Thanks for explaining. The reasons behind the savepoint being restored
successfully kind of make sense, but it seems like the window type (count
vs time) should be taken into account when restoring savepoints. I don't
actually see anyone doing this, but I would expect flink to complai
For a WindowedStream the uid would be set on the result of the
apply/reduce/fold call. The WindowedStream itself does not represent an
operation.
On Fri, 13 May 2016 at 00:20 Ufuk Celebi wrote:
> On Thu, May 12, 2016 at 10:44 PM, Andrew Whitaker
> wrote:
> > From what I've observed, most of the
On Thu, May 12, 2016 at 10:44 PM, Andrew Whitaker
wrote:
> From what I've observed, most of the time when Flink can't successfully
> restore a checkpoint it throws an exception saying as much. I was expecting
> to see that behavior here. Could someone explain why this "works" (as in,
> flink accep
"Flink can't successfully restore a checkpoint" should be "Flink can't
successfully restore a savepoint".
On Thu, May 12, 2016 at 3:44 PM, Andrew Whitaker <
andrew.whita...@braintreepayments.com> wrote:
> Hi,
>
> I was recently experimenting with savepoints and various situations in
> which they
Hi,
I was recently experimenting with savepoints and various situations in
which they succeed or fail. I expected this example to fail:
https://gist.github.com/AndrewWhitaker/fa46db04066ea673fe0eda232f0a5ce1
Basically, the first program runs with a count window. The second program
is identical e
