[
https://issues.apache.org/jira/browse/FLINK-21308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17363595#comment-17363595
]
Stephan Pelikan commented on FLINK-21308:
-----------------------------------------
Hi Igal,
Thank you for asking for feedback :)
Yes, if one can define a custom messageId and use this id to undo delayed
sending than this is fine. Doing so one could also construct a message
including this messageId if needed.
The only reason for supposing a lambda is to reuse an internal message id to
keep the state small. Maybe your implemenations does not need an extra internal
id then using a custom id would lead to a similar state size.
Another question: Will subsequent calls to sendAfter using the same custom
messageId replace previous timed messages using the same messageId, will it
throw an expection or will both messages be sended at each delayed point in
time? If one registers two messages of the same id and different times, will
all be undelayed or just one on calling unsendDelayedMessage? I guess the API
is fine but the behavior in those edge cases should be defined and documented.
Besides the basic functionality I requested, additional flexibility would be
nice but not necessary since updates could also be done be unsending the
previous message and doing a new sendAfter.
Cheers,
Stephan
> 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
> Assignee: Igal Shilman
> Priority: Major
> Labels: auto-deprioritized-major, stale-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)
