Brian Zhou
Brian Zhou
As the reactive container mode will soon come out in the Flink 1.13 release, the rescaling seems to have a new approach to do by registering more taskmanagers to the...
Since #651 is fixed, this PR can target the latest master branch.
I support the first approach. It follows the rule "who create who delete" and is enough for restarting with checkpoint-enabled cases. It's not ideal to delete the reader group out...
> Could we not rely on random strings and use a well-defined and known name? As reader group(or say `SourceFunction` in Flink) is known to the Flink as a single...
Thanks for the comment. @EronWright Here is what I'd like to explain. > ``` > rowtime: > timestamps: > type: from-field > watermarks: > type: from-source > ``` This one...
> recovering with the newly-spawned reader may get data loss as the related operators rolls its state back to the last checkpoint Say if one reader reading three events: 1,2...
I'm not hanging up the idea that it should be the same reader, I was thinking the reader recovery should involve a roll back, while Pravega has all the segment...
@tkaitchuck The partial recovery is the problem we want to solve in the Flink connector, not in Pravega itself, so I would still put it like this. You are right...
Any progress on this PR? @derekm
> 1- @crazyzhou it would help if you explained in more detail and focused on the behavior you are trying to implement. My understanding is the following: upon recovery, you...