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
