Hi
Thanks for the multiple responses on this question.
Please correct me if I am wrong about the 3 possible ways of it:
1. As per FLINK-3089, RocksDB based timer implementation is efficient. But
it is not merged yet. Which release this will be part of?
2. FLINK-6359 suggests alternate approach bas
Here are the thoughts why I advocated to not expose the "delete" initially:
(1) The original heap timer structure was not very sophisticated and
could not support efficient timer deletion (as Gyula indicated). As a core
rule in large scale systems: Never expose an operation you cannot do
efficie
Logged FLINK-6359, referring to this thread.
FYI
On Sat, Apr 22, 2017 at 1:10 AM, Gyula Fóra wrote:
> Hi,
>
> I am not familiar with this data structure, I will try to read up on it.
> But it looks interesting.
>
> For some reference, some links:
>
> https://www.confluent.io/blog/apache-kafka-p
Hi,
I am not familiar with this data structure, I will try to read up on it.
But it looks interesting.
For some reference, some links:
https://www.confluent.io/blog/apache-kafka-purgatory-hierarchical-timing-wheels/
http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf
Cheers
Benjamin has an implementation for Hierarchical Timing Wheels (Apache
License) :
https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/TimerWheel.java
If there is some interest, we can port the above over.
Cheers
On Fri, Apr 21, 2017 at 12:4
The timer will actually fire and will be removed at the original time, but
we don't trigger any action on it. We also remove the tombstone state
afterwards.
So we use more memory yes depending on the length and number of timers that
were deleted. But it is eventually cleaned up.
Gyula
Ted Yu ez
A bit curious: wouldn't using "tombstone" markers constitute some memory
leak (since Timers are not released) ?
Cheers
On Fri, Apr 21, 2017 at 12:23 PM, Gyula Fóra wrote:
> Hi!
>
> I thought I would drop my opinion here maybe it is relevant.
>
> We have used the Flink internal timer implementat
Hi!
I thought I would drop my opinion here maybe it is relevant.
We have used the Flink internal timer implementation in many of our
production applications, this supports the Timer deletion but the deletion
actually turned out to be a huge performance bottleneck because of the bad
deletion perfo
Hi,
the reasoning behind the limited user facing API was that we were (are) not
sure whether we would be able to support efficient deletion of timers for
different ways of storing timers.
@Stephan, If I remember correctly you were the strongest advocate for not
allowing timer deletion. What’s y
Hi
I am working on a use case where I want to start a timer for a given event
type and when that timer expires it will perform certain action. This can
be done using Process Function.
But I also want to cancel scheduled timer in case of some other types of
events. I also checked the implementatio
10 matches
Mail list logo
