Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Mar 22, 2010 · 9 comments
Labels
has: votes-jira in: core type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Mar 22, 2010

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:

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 22, 2010

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Sep 18, 2010

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 19, 2011

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 7, 2011

Tristan Burch commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Dec 16, 2011

Ryan Tenney commented

Any chance we could get this in 3.1.1?

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 8, 2012

Tristan Burch commented

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

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 8, 2012

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 2, 2012

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented May 22, 2012

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
> ```

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
has: votes-jira in: core type: enhancement
Projects
None yet
Development

No branches or pull requests

1 participant