Spring Framework
  1. Spring Framework
  2. SPR-7022

Support initial delay attribute for @Scheduled and <task:scheduled>

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.2 M1
    • Component/s: Core
    • Labels:
      None
    • Last commented by a User:
      false

      Description

      @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)

        Issue Links

          Activity

          Hide
          Dan Checkoway added a comment -

          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.

          Show
          Dan Checkoway added a comment - 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.
          Hide
          Oliver Siegmar added a comment -

          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"/>
          
          Show
          Oliver Siegmar added a comment - 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" />
          Hide
          Timo Rumland added a comment -

          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.

          Show
          Timo Rumland added a comment - 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.
          Hide
          Tristan Burch added a comment -

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

          Show
          Tristan Burch added a comment - I'd love to see annotation and namespace support for this!
          Hide
          Ryan Tenney added a comment -

          Any chance we could get this in 3.1.1?

          Show
          Ryan Tenney added a comment - Any chance we could get this in 3.1.1?
          Hide
          Tristan Burch added a comment -

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

          Show
          Tristan Burch added a comment - Maybe it can be fixed in 3.1.2 or even 3.2M1?
          Hide
          Chris Beams added a comment -

          "Scheduled" for 3.2 M1, pun intended

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

          Show
          Chris Beams added a comment - "Scheduled" for 3.2 M1, pun intended @Dan, consider submitting your original patch as a pull request by following the contributor guidelines
          Hide
          Paul Khodchenkov added a comment -

          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.

          Show
          Paul Khodchenkov added a comment - 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.
          Hide
          Chris Beams added a comment -

          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
          
          
          Show
          Chris Beams added a comment - 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

            People

            • Assignee:
              Chris Beams
              Reporter:
              Dan Checkoway
              Last updater:
              Trevor Marshall
            • Votes:
              25 Vote for this issue
              Watchers:
              24 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                1 year, 47 weeks ago

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - Not Specified
                Not Specified
                Logged:
                Time Spent - 2d
                2d