Hi Andrey,

Thank you. That makes sense. Looking at the code of how TTL is
implemented, it matches exactly what you said.

Ning

On Wed, Dec 5, 2018 at 9:37 AM Andrey Zagrebin <and...@data-artisans.com> wrote:
>
> Hi Ning,
>
> State backends store the timestamp of last access/modification of state with 
> TTL.
> This absolute timestamp does not depend on the configured time-to-live.
> If you restart a job from the savepoint and configure longer time-to-live 
> than before,
> it just means that map state entries, which have not been cleaned up before 
> savepoint,
> and newly added entries will expire later relative to their originally saved 
> access timestamp.
>
> Best,
> Andrey
>
> > On 5 Dec 2018, at 04:20, Ning Shi <nings...@gmail.com> wrote:
> >
> > I have a job using TTL map state and RocksDB state backend. If I
> > lengthen the TTL on the map state and resume the job from savepoint (or
> > checkpoint assuming I don't change the state backend), will new values
> > added to that map have the new TTL or will the old TTL in the savepoint
> > override my changes?
> >
> > Thanks,
> >
> > Ning
>

Reply via email to