Support initial delay attribute for @Scheduled and <task:scheduled> [SPR-7022]

[spring-projects-issues]

Dan Checkoway opened SPR-7022 and commented

@Scheduled is the coolest thing ever...but it could really use an "initialDelay" parameter. Otherwise there's no way (that I'm aware of) to configure a @Scheduled method to run after a specified delay.

Without it, I'm forced to use the likes of TaskScheduler.scheduleAtFixedRate(Runnable, Date, long) and pass it a startDate...and then I'm forced to wrap a Runnable around my method, etc. That's so old school! :-)

Anyway, please consider my humble request for an optional "initialDelay" such as:
@Scheduled(fixedRate=60000,initialDelay=20000)
and
@Scheduled(fixedDelay=30000,initialDelay=30000)

---

Attachments:

• scheduled-initial-delay-patch.diff (12.61 kB)

Issue Links:

• #12374 Deadlock between DefaultListableBeanFactory and DefaultSingletonBeanRegistry, perhaps due to lazily-instantiated aspect

Referenced from: commits 5330c52, 53673d6

25 votes, 24 watchers

[spring-projects-issues]

Dan Checkoway commented

Attached is a patch that should work. I'm pretty new to contributing to Spring Framework, so I'm honestly not too sure how to build it.

But hopefully you'll be able to give this a shot. The idea is that instead of using Map<Runnable, Long> to convey the task configuration to the ScheduledTaskRegistrar, it uses Lists with new objects CronTask, FixedDelayTask, and FixedRateTask. The latter two are able to store both the initialDelay and fixedDelay or fixedRate, respectively.

[spring-projects-issues]

Oliver Siegmar commented

Please note, that this support should also be added to the scheduled element in Spring's task namespace -

<task:scheduled ref="myService" method="reload" fixed-delay="60000" initial-delay="30000"/>

[spring-projects-issues]

Timo Rumland commented

I vote for this. The "initialDelay" was one of the first things I looked for when I started using the <task:scheduled.. /> tags. I use annotations heavily, but configuring scheduled service methods is one of the few things I really like doing in XML to keep the overview.

[spring-projects-issues]

Tristan Burch commented

I'd love to see annotation and namespace support for this!

[spring-projects-issues]

Ryan Tenney commented

Any chance we could get this in 3.1.1?

[spring-projects-issues]

Tristan Burch commented

Maybe it can be fixed in 3.1.2 or even 3.2M1?

[spring-projects-issues]

Chris Beams commented

"Scheduled" for 3.2 M1, pun intended :)

@Dan, consider submitting your original patch as a pull request by following the contributor guidelines

[spring-projects-issues]

Paul Khodchenkov commented

Absence of initial-delay parameter often cause the deadlock on startup
https://jira.springsource.org/browse/SPR-7718
I have to use quartz to workaround this problem.

[spring-projects-issues]

Chris Beams commented

Available now in 3.2.0.BUILD-SNAPSHOT via repo.springsource.org. See here if you haven't dealt with snapshots before. Enjoy!

commit 53673d6c598a587ab1e511bbce14ba8b686f8951
Author: Chris Beams <cbeams@vmware.com>
Date:   Wed Mar 14 18:14:28 2012 +0200

    Support initial delay attribute for scheduled tasks
    
    java.util.concurrent's ScheduledExecutorService and its #schedule*
    methods allow for an 'initialDelay' parameter in milliseconds.
    Similarly, Spring's TaskExecutor abstraction allows for a concrete
    'startTime' expressed as a Date. However, Spring's <task:scheduled> XML
    element and @Scheduled annotation have, to date, not allowed for an
    initial delay parameter that can be propagated down to the underlying
    TaskScheduler/ScheduledExecutorService.
    
    This commit introduces initial-delay and #initialDelay attributes to
    task:scheduled and @Scheduled respectively, both indicating the number
    of milliseconds to wait before the first invocation of the method in
    question. Specifying a delay in this fashion is only valid in
    conjunction with fixed-rate and fixed-delay tasks (i.e. not with cron
    or trigger tasks).
    
    The principal changes required to support these new attributes lie in
    ScheduledTaskRegistrar, which previously supported registration of
    tasks in the form of a Runnable and a Long parameter indicating (in the
    case of fixed-rate and fixed-delay tasks), the interval with which the
    task should be executed. In order to accommodate a third (and optional)
    'initialDelay' parameter, the IntervalTask class has been added as a
    holder for the Runnable to be executed, the interval in which to run
    it, and the optional initial delay. For symmetry, a TriggerTask and
    CronTask have also been added, the latter subclassing the former. And a
    'Task' class has been added as a common ancestor for all the above.
    
    One oddity of the implementation is in the naming of the new
    setters in ScheduledTaskRegistrar. Prior to this commit, the setters
    were named #setFixedDelayTasks, #setFixedRateTasks, etc, each accepting
    a Map<Runnable, long>. In adding new setters for each task type, each
    accepting a List<IntervalTask>, List<CronTask> etc, naturally the
    approach would be to use method overloading and to introduce methods
    of the same name but with differing parameter types. Unfortunately
    however, Spring does not support injection against overloaded methods
    (due to fundamental limitations of the underlying JDK Introspector).
    This is not a problem when working with the ScheduledTaskRegistrar
    directly, e.g. from within a @Configuration class that implements
    SchedulingConfigurer, but is a problem from the point of view of the
    ScheduledTasksBeanDefinitionParser which parses the <task:scheduled>
    element - here the ScheduledTaskRegistrar is treated as a Spring bean
    and is thus subject to these limitations. The solution to this problem
    was simply to avoid overloading altogether, thus the naming of the new
    methods ending in "List", e.g. #setFixedDelayTasksList, etc. These
    methods exist primarily for use by the BeanDefinitionParser and are
    not really intended for use by application developers. The Javadoc for
    each of the new methods makes note of this.
    
    Issue: SPR-7022

> ```