-
Notifications
You must be signed in to change notification settings - Fork 38.8k
Description
Context
Consider this method
@Scheduled(fixedDelay = 1000)
void job()
{
// some syncronous work
}The job() method can be counted upon to never be called until the previous run of job() is finished.
Now consider this method
@Scheduled(fixedDelay = 1000)
void job()
{
someAsyncMethodReturningAMono()
.subscribe()
}Here, job() would be called 1000ms after the previous run of job() returns, not when the the Mono returned by someAsyncMethodReturningAMono() would terminate. If the asynchronous work takes just over a bit longer than 1000ms, it may run at the same time as previous runs. This can be mitigated by using the .block() statement to subscribe to someAsyncMethodReturningAMono(), effectively making job() syncronous again, but it would be better to have a non-blocking answer to this.
Proposal
To let @Scheduled's fixedDelay property, when the annotated method returns a Mono or a Flux, start the delay count from the moment the returned Mono or Flux terminates instead of when the method returns the Mono, so that one can write this:
@Scheduled(fixedDelay = 1000)
Mono job()
{
return someAsyncMethodReturningAMono();
}This code would resonate with WebFlux users nicely.