t;>>> I am +1 for the change which stores timers in RocksDB by default.
>>>>
>>>> Some users hope the checkpoint could be completed as fast as possible,
>>>> which also need the timer stored in RocksDB to not affect the sync part of
>>>>
> also need the timer stored in RocksDB to not affect the sync part of
> checkpoint.
>
> Best
> Yun Tang
> From: Andrey Zagrebin mailto:azagre...@apache.org>>
> Sent: Friday, January 17, 2020 0:07
> To: Stephan Ewen mailto:se...@apache.org>>
> Cc: dev mailto
ot affect the sync part of
>>> checkpoint.
>>>
>>> Best
>>> Yun Tang
>>> --
>>> *From:* Andrey Zagrebin
>>> *Sent:* Friday, January 17, 2020 0:07
>>> *To:* Stephan Ewen
>>> *Cc:* d
>> *From:* Andrey Zagrebin
>> *Sent:* Friday, January 17, 2020 0:07
>> *To:* Stephan Ewen
>> *Cc:* dev ; user
>> *Subject:* Re: [DISCUSS] Change default for RocksDB timers: Java Heap =>
>> in RocksDB
>>
>> Hi Stephan
fect the sync part of
> checkpoint.
>
> Best
> Yun Tang
> --
> *From:* Andrey Zagrebin
> *Sent:* Friday, January 17, 2020 0:07
> *To:* Stephan Ewen
> *Cc:* dev ; user
> *Subject:* Re: [DISCUSS] Change default for RocksDB timers: Java Heap =>
&
: Andrey Zagrebin
Sent: Friday, January 17, 2020 0:07
To: Stephan Ewen
Cc: dev ; user
Subject: Re: [DISCUSS] Change default for RocksDB timers: Java Heap => in
RocksDB
Hi Stephan,
Thanks for starting this discussion. I am +1 for this change.
In general, number of timer state keys can have the s
Hi Stephan,
Thanks for starting this discussion. I am +1 for this change.
In general, number of timer state keys can have the same order as number of
main state keys.
So if RocksDB is used for main state for scalability, it makes sense to
have timers there as well
unless timers are used for only
Hi all!
I would suggest a change of the current default for timers. A bit of
background:
- Timers (for windows, process functions, etc.) are state that is managed
and checkpointed as well.
- When using the MemoryStateBackend and the FsStateBackend, timers are
kept on the JVM heap, like
