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.