ArithmeticException: long overflow on @Scheduled(fixedDelay = Long.MAX_VALUE)

[ipalbeniz]

Affects: 6.0.10

---

I was scheduling a task using @Scheduled(fixedDelay = Long.MAX_VALUE) in Spring version 6.0.9. The intention was to schedule the task only once. However, after upgrading to version 6.0.10, the application fails to start with the following exception:

java.lang.ArithmeticException: long overflow
	at java.base/java.lang.Math.multiplyExact(Math.java:1004)
	at java.base/java.time.Duration.toNanos(Duration.java:1250)
	at org.springframework.scheduling.concurrent.ThreadPoolTaskScheduler.scheduleWithFixedDelay(ThreadPoolTaskScheduler.java:420)

It seems that the method ThreadPoolTaskScheduler.scheduleWithFixedDelay() was changed in commit 3415b04, which is referenced by issue #30666. This change modifies the delay time unit from milliseconds to nanoseconds. I suspect that this alteration may be the cause of the exception.

[jhoeller]

Technically, there was always a risk of an overflow there but previously you could only trigger that via fixedDelay = Long.MAX_VALUE, timeUnit = TimeUnit.SECONDS or the like, whereas now it can be triggered with the default milliseconds unit. We'll see what we can do about this, falling back to millisecond or even second precision when necessary.

[jhoeller]

There is a more idiomatic solution: We can use JDK 11's long TimeUnit.convert(Duration) method which prevents arithmetic overflows, turning them into Long.MAX_VALUE instead. After all, such large values just mean arbitrary long out anyway, precision does not really matter there. Whereas for shorter delays and periods, nano precision is certainly beneficial.

[ipalbeniz]

Thank you so much @jhoeller !

[cmuchinsky]

@jhoeller I'm seeing a similar overflow exception coming from https://github.com/spring-projects/spring-framework/blob/main/spring-context/src/main/java/org/springframework/scheduling/concurrent/ReschedulingRunnable.java#L83, should the same fix be applied to that as well?