Dear Igal,Very insightful answer. Thanks. Igal Shilman wrote > An alternative approach would be to implement a * > thumbling window * > per vertex(a stateful function instance)by sending to itself a delayed > message [2]. When that specific delayedmessage arrives you wouldhave to > purge the oldest edges by examining the edges in state.
Indeed, the delayed asynchronous messages are a workaround for *tumbling window* simulation in SF. I believe you assume a message received by a stateful function contains multiple edges, i.e. which can all be delayed by a certain amount of time. Therefore, when a function receives a message, it purges all of its existing edges and incorporates the new (delayed) ones.Correct?Nevertheless, if you think of it, the delay is essentially the *window slide*. Now, what about the *window range*? Igal Shilman wrote > Data stream windows are not yet supported in statefun, but it seems > likethe main motivation hereis to purge old edges?If this is the case > perhaps we need to integrate state TTL [1] intopersisted > values/persistedtables. I was not aware about the TTL, very interesting and handful. Essentially, the TTL can enforce the *window range* i.e., attach to each tuple received by a stateful function its lifespan/duration. So, the first TTL attribute sets the range /StateTtlConfig.newBuilder(Time.seconds(*window range*))/.Therefore, by *combining TTL and SF Delayed Messaging* we can *simulate sliding window* processing on a stateful function basis.However, TTL is a Flink constuct and I am not sure if I got it correctly. You said Igal Shilman wrote > If this is the case perhaps * > we need to integrate * > state TTL [1] intopersisted values/persistedtables. If this is the case, then I believe it would be great to integrate TLL into Persisted Values/Tables <https://ci.apache.org/projects/flink/flink-statefun-docs-release-2.0/sdk/java.html#persistence> . -- Sent from: http://apache-flink-user-mailing-list-archive.2336050.n4.nabble.com/
