You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's a common pattern using iwf workflow like this:
class UpdatableTimerState implements WorkflowState<Void> {
@Override
public CommandRequest waitUntil(Context context, ...) {
return CommandRequest.forAnyCommandCompleted(
TimerCommand.createByDuration(TIMEOUT_DURATION)),
InternalChannelCommand.create(CHANNEL_RESET_TIMER)
);
}
@Override
public StateDecision execute(Context context, Void input, CommandResults commandResults,...) {
TimerCommandResult timer = commandResults.getTimerResult(0);
if (timer.getStatus() == FIRED) {
// timer fires, call API to send an email
svc.sendEmail(...);
// assuming we want to complete workflow here
return StateDecision.completeWorkflow();
}
// otherwise the channel receives a message to reset the timer
return StateDecision.singleNextState(UpdatableTimerState.class);
}
When doing this, a new timer would always created when receiving a REST TIMER message.
We could potentially lazily create it when needed. For example --
if the first timer is 30 days, and after one day, it tries to create another 30 day timer, after another day, it will create another 30 day timer again, so there are 3 timers created in history.
Instead, we could keep the first timer, and only create a new timer when the first timer is fired, and check if there is another timer needed.
Note that this optimization is now possible to implement relatively easy because iwf has a dedicated component to manage all the timers -- TimerProcessor:
It contains all the real timers in member fields stateExecutionCurrentTimerInfos
continueAsNew is implemented already for it.
The temporal timers are actually started in a centralized place in WaitForTimerFiredOrSkipped method.
So technically this optimization can be done within this component, without changing anything else.
It would be safer to enable by config, then later on when it's stable, use versioning to enable for all.
The text was updated successfully, but these errors were encountered:
It's a common pattern using iwf workflow like this:
When doing this, a new timer would always created when receiving a REST TIMER message.
We could potentially lazily create it when needed. For example --
if the first timer is 30 days, and after one day, it tries to create another 30 day timer, after another day, it will create another 30 day timer again, so there are 3 timers created in history.
Instead, we could keep the first timer, and only create a new timer when the first timer is fired, and check if there is another timer needed.
Note that this optimization is now possible to implement relatively easy because iwf has a dedicated component to manage all the timers -- TimerProcessor:
stateExecutionCurrentTimerInfos
WaitForTimerFiredOrSkipped
method.So technically this optimization can be done within this component, without changing anything else.
It would be safer to enable by config, then later on when it's stable, use versioning to enable for all.
The text was updated successfully, but these errors were encountered: