[
https://issues.apache.org/jira/browse/FLINK-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17342615#comment-17342615
]
Stephan Pelikan commented on FLINK-21308:
-----------------------------------------
Sorry for not responding to your questions. I'm busy at the moment.
For me any implementation is fine. My pull request was just a suggestion. You
know the internals better than I do.
{quote}2) I didn't understand why sendAfter now receives a Function<> ?
{quote}
Doing so the "timer id" can be part of the message which will be sent delayed:
{code:java}
context.getFlinkContext().sendAfter(
duration,
context.getFlinkContext().self(),
messageId -> {
return TimerMessage.newBuilder()
.setElementId(elementId)
.setTokenId(tokenId)
.setTimerId(messageId)
.build();
});
{code}
The reason for that: I have to store the message id in my statefun's state so,
if I decide to cancel the timer I know the timer id. Since I'm tracking
concurrent events of one particular business workflow (the statefun) I have to
store all the timer ids which I need for that workflow in the state - not only
one. If a timer was not cancelled the message will be delivered and I have to
know which timer id this message belongs to, so I can cleanup the statefun's
state. So the timer id needs to be part of the delayed message.
Maybe we should introduce a convinience method for those who do not need the
timer id as part of the message.
> Cancel "sendAfter"
> ------------------
>
> Key: FLINK-21308
> URL: https://issues.apache.org/jira/browse/FLINK-21308
> Project: Flink
> Issue Type: New Feature
> Components: Stateful Functions
> Reporter: Stephan Pelikan
> Priority: Major
> Labels: auto-deprioritized-major
> Fix For: statefun-3.1.0
>
>
> As a user I want to cancel delayed sent messages not needed any more to keep
> state clean.
> Use case:
> {quote}My use-case is processing business events of customers. Those events
> are triggered by ourself or by the customer depending of what's the current
> state of the ongoing customer's business use-case. We need to monitor
> delayed/missing business events which belong to previous events. For example:
> the customer has to confirm something we did. Depending on what it is the
> confirmation has to be within hours, days or even months. If there is a delay
> we need to know. But if the customer confirms in time we want to cleanup to
> keep the state small.
> {quote}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
