Hello,
I’m exploring the functionality of Temporal Schedules using the java-sdk and have been following this sample as a guideline.
What I am trying to do, is schedule a workflow to start at a specific date and time, that runs n
times, every s
seconds. For example, first workflow starts June 6, 2023 at 9:00am, then runs 5 times every 10 seconds subsequently.
Using setInterval
seems to dismiss the setCalendar
part of the spec and begins running the workflows prior to the specified date and time (though at the appropriate interval).
Can someone help me understand how I might be misusing the Schedule functionality or how to implement my intended use?
Thanks!
starts June 6, 2023 at 9:00am, then runs 5 times every 10 seconds subsequently.
Can you give more info on what exactly you mean by this ?
If it means “run 5 executions total, each 10s apart” you could do
Schedule schedule =
Schedule.newBuilder()
.setAction(action)
.setSpec(
ScheduleSpec.newBuilder()
.setStartAt(Instant.now().plus(3, ChronoUnit.MINUTES))
.setIntervals(
Collections.singletonList(new ScheduleIntervalSpec(Duration.ofSeconds(10))))
.build())
.setState(
ScheduleState.newBuilder()
.setLimitedAction(true)
.setRemainingActions(5).build())
.build();
If it means “start at date X and then run every 2 seconds” then you can
set interval to 2s and remove limited and remaining actions.
If it means something else please share.
This was helpful. I believe I was conflating the two ideas of a Calendar-based schedule firing and scheduling the very first Workflow. My confusion made it seem that the interval-based firings would trigger immediately, ignoring the “fire at this specific time” schedule. But from your clarification, if I’m understanding correctly, it would be supplemental e.g., fire immediately at this interval, but also at this specific time. Whereas I was wanting, “start at this specific moment, then at this interval subsequently”. Thanks for clarifying, I’m hoping I got that right.
Is this approach using the new Schedule mentioned here Temporal v1.20: Improved Dev Environments & Workflow Scheduling? I thought it was not available in java yet.
Can you explain the expected behavior when a Workflow is started by the Schedule with no Worker? I am trying to understand this by intentionally waiting to create a Worker until after the Schedule has fired several times. I had expected it to still run any ScheduledActions (Workflows) that were missed within the Catchup Window, but it seems to only run these if the appropriate Overlap Policy is set. Is this the intention of specifying/using the functionality of the Catchup Window or should you be able to have those run by exclusively using the Catchup Window? Am I missing something else altogether? Thanks in advance!
Yes that is expected, default overlap policy is SCHEDULE_OVERLAP_POLICY_SKIP meaning if you don’t have your worker running your initially started schedule would never complete (make progress) so next invocation would not be started. So in your case seems you might want to use SCHEDULE_OVERLAP_POLICY_ALLOW_ALL (or terminate)?
Can I ask what is the problem with having your worker processes running at all times?
No problem. Mostly trying to grasp an understanding of the different aspects of these Schedules. A question had arisen regarding the behavior if the worker happened to crash/was not initialized properly, what would the Schedule do in those cases? But I think your answer clears that up. The Schedule will just keeping firing (assuming the spec says so) off the next Workflows and behave according to the Overlap Policy until another Worker can pull from the queue? Is that more or less accurate?
Workflow executions are created by the service, it creates and durably persists the execution then this creation of execution needs to be delivered (via first workflow task) to your workers to start running your workflow code. If I understand your question correctly, its the same thing with schedules, if you start one or multiple ones given the overlap policy they would not be able to make progress until your workers are up and polling of the executions task queues.
1 Like