t as possible, which
> 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>>
ored in RocksDB to not affect the sync part of
>>> checkpoint.
>>>
>>> Best
>>> Yun Tang
>>> --
>>> *From:* Andrey Zagrebin
>>> *Sent:* Friday, January 17, 2020 0:07
>>> *To:* Stephan Ewen
>
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 =>
>> in RocksDB
>>
&g
not affect 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 v
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 regula
